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: oswin krause (oswin.krause_at_[hidden])
Date: 2015-03-19 10:51:14

Hi,
> If Robert is holding back a fix to Seralisation, I would be sure he
> has a very good reason to do so.
I trust him. However, in the ticket regarding the bug, he told me that 
it is fixed in development and that I could check out the development 
branch if I needed it very urgently. This was for me a "should be 
available in the next release" which was enough for me to not poke any 
further. But it is now 2 releases since then. If there were problems I 
would have liked to hear about it as I would have been willing to test 
and/or provide further patches.
> Most Boost libraries with active maintainers are pretty good about
> merging develop to master regularly. Those libraries without active
> maintainers I would personally avoid as you're always going to be
> fighting to find someone willing to merge fixes.
Is there a list of libraries searching a new active maintainer? It does 
not really state in the official documentation which libraries to stay 
away from and i am not remembering people asking for some bug-fix 
maintainers. I would certainly willing to clean up the bug-tracker of 
one of the libraries I use. On the other hand: i do not mind bugs in a 
library I just mind bugs in a library that just pop up after an update.

> A huge advantage of header only Boost libraries is you are free of
> dependency on the system provided version. Although you shouldn't do
> this, often you can get away with replacing a header only library
> locally with the latest, yet still link to the shared library
> dependencies of a much older Boost version. I should stress the "get
> away with" part of that statement.
I do not really want to run into ODR violations(and serialization is not 
header only). I was thinking about providing my own code for this file 
and just include it first, trying to diagnose if the "official" version 
was included first and bail out with an error if it was. But this is a) 
super messy b) prone to ODR violations and c) i have to maintain the fix 
for several years.

The cleanest solution for a regression like this would be if the fix 
would be out and a patch would be available so that we can poke the 
distro maintainers to include it into their libboost-1.56/7/8.