Re: [Boost-users] what happens between "fixed in development" and "available in release"?

Subject: Re: [Boost-users] what happens between "fixed in development" and "available in release"?
From: Thomas (firespot71_at_[hidden])
Date: 2015-03-20 03:43:14

On 19/03/2015 18:23, Robert Ramey wrote:
> Niall Douglas wrote
>> On 19 Mar 2015 at 8:41, Robert Ramey wrote:
>> Personally speaking, I'd do that exact merge straight after a Boost
>> release. That gives you the time to find and fix any problems before
>> the next release. In other words, develop lags master by one major
>> Boost release.
>
> My practice is to
>
> a) decide to address something - feature tweak like adding support for std
> smart pointers, fixing outstanding bugs or whatever.
> b) fix them in develop.  This includes ancillary stuff like adjusting
> documentation
> c) run my test scenario as described above
> d) merge into master.
>
> I do this independent of the release schedule and do it is "smallish"
> chunks.  This generally works pretty well and the serialization library on
> the master is of the state "no known fixable bugs".  It does suck a lot of
> CPU time but that's free for me now.  The problem comes when something
> "breaks".  I might forget how to do something, the build system might have
> evolved, etc.  Then I have to call some mental subroutine which takes a lot
> of time to get back on track.  The risk of this happening dissuades me from
> doing this procedure more often.   In this particular case, he release came
> up in the middle of my cycle.

I am just a boost user, not developer, and don't follow this list 
closely. Here are my 2 cents, I hope they are not completely off:

What about making an upcoming release, e.g. 1.59, a "bug-fix" release 
only with the goal that all (or almost all) open issues get merged to 
master? No new features get added.
If a library is stable (i.e. no open issues) leave it as it is (freeze 
it) and communicate that to other maintainers, so they can rely on a 
given version. Same for boost build and other tools, provide reference 
versions to rely on, no extensions. Give maintainers the time to get 
their issues fixed, do thorough testing etc. - if it takes half a year 
or longer, so it be, fine.

As user I too find it increasingly difficult to overview the status and 
reliability of boost versions, and switching to a new release can make 
matters worse (for me as user) then sticking to a "working" previous 
release.
On the other hand I think that I can understand the tremendous amount of 
effort and commitment required from library maintainers. And yes I know 
that things can break so unexpectedly and distract for ages from main 
aims (last time here: a VS extension installed broke the default 
configurations set by boost build, and that did take us a lot of time). 
So as user I feel the responsibility to not expect miracles or 
unrealistic things from maintainers.

Note that my proposal aims at helping both users and maintainers: The 
former to get a hopefully stable release, and the latter to give them 
the time needed to make their developments and testing, without 
everything else in boost changing all the time.

Thomas