Boost Users :
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
> 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
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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net