Boost Users :
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
> 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.
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