Re: [boost] [Boost-users] Maintenace Guidelines wiki page

Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-22 16:12:03

----- Original Message ----- 
From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost-users_at_[hidden]>
Cc: <boost_at_[hidden]>
Sent: Saturday, November 22, 2008 9:19 PM
Subject: Re: [Boost-users] Maintenace Guidelines wiki page

> 
> This is a laudable effort, 

Thanks.

> but my guess is that it's doomed to failure.
> 
> My own take on this was posted in 
> http://lists.boost.org/Archives/boost/2008/07/139893.php

I remember your participation and your point of view on this long thread.

> So far, no one else has endorsed such a pledge.  Indeed, the responses 
> suggested that
> the breaking interfaces was a normal, acceptable and unavoidable practice.

I don't think this is the case. Breaking changes should be exceptional and taken because there is no better solution. I think that most of the Boost authors respect that. As every rule this one has its exceptions, there has been some library evolution that have break user and even Boost library code. This is regretable and we need to setup whatever is needed to make this exceptions more than exceptional. I really think that *we can* achieve this goal.

> I think that differing points of view reflect different backgrounds of 
> different
> developers.  In my particular case, I work on relatively short term projects
> under huge pressure to produce results.  I absolutely depend upon boost
> and other libraries (e.g. MFC) to get the job done.  If a library changes, 
> then
> I have to go back and re-visit something that was already considered 
> "finished".
> The creates a big problem for me.

I understand your concern.
 
> In other environments, programmers work on huge projects which might
> go on for years.  In this constext, this is not such a huge problem as 
> things
> are constantly evolving anyway.  So continuing to break things and
> having to fix them is a normal and in any event unavoidable.

Even in this case breaking code is a inacceptable because there is a lot of code to modify and test. So if we want that the Boost library is used widely we need to *try* to provide backward compatible versions, and warm when this is no more possible.
In my personal work, we use to do provide some scripts that either they are able to automaticaly do the complete transformation or they warm when automatic transformation is not possible. Usualy this let 20% of the code to be transformed manually.
 
> Your "Maintainence Guidlines" presume a consensus
> about what should be acceptable practice where no
> such consensus actually exists.

Which acceptable practice are you referring to for which there is no consensus?
 
> As a practical matter what do I do.
> 
> I need a facility.  My experience would suggest that such
> a facility might be already existing in some sort of library.
> According to the situation, I will review a couple of candidates
> and select one to try.  It might be a commercial product or
> it might be something like boost. Then I'll try to introduce
> the library to my code.  This has to be pretty easy or I'll discard it.
> It needs to have good documentation and it needs to "just work"
> I then copy the library in to my project. I try to avoid making
> a big commitment to a library - or anyone else's code so
> that I can drop one library if I have to in the future.
> 
> With the serialization library, it has to include the latest
> boost libraries that it uses.  If I find that the library
> author can't maintain a stable and relieable product,
> I design that library out of the serialization library.  This
> has happened several times.  Given the fact that
> the serialization library is not my full time job
> (though at times it seems that way), I don't feel
> there is any real alternative.

I hope that you are not proposing that to the end users. Are you?

Please could you participate in the elaboration of this guidelines, your opinion is very important to the Boost community.

Thanks,
Vicente