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