Boost logo

Boost :

From: Loïc Joly (loic.actarus.joly_at_[hidden])
Date: 2006-02-02 15:45:47

Martin Bonner a écrit :
> From: David Maisonave
>>The poll results were suprising.
> I was responding specifically to the implication that it was suprising
> that the percentages added to >100%.
>>I would have thought by now there
>>would be more developers using 7.1/8.0 than 6.0.
>>If Boost decides to stop supporting VC++ 6.0, or reduce support, than
>>they're going to exclude at lot of developers.
> Not really. Changing boost library version is probably less painful
> than changing compiler version, but I wouldn't do either without
> compelling reason.
> VC6 users can use boost 1.33.1 (or perhaps even 1.34), and that isn't
> going to suddenly stop working just because 1.35 doesn't support VC6.

No, but if I know that in boost 1.35, some of the bugs that are
pesterring me have been corrected, but I cannot use these fixes, I would
have to face one choice :
- Upgrading my compiler, that may be inconvenient
- Correcting boost myself, that is not why I use an external library
- Use only home made stuff, less generic, less adaptable, but that I can

As far as I understand (please tell me if I'm wrong), there is only one
supported version of boost. If I discover a bug in boost::xx, next
version of boost will have the correction, but the correction will not
be back-ported to older versions, even if the bug was already there.

This situation if perfectly acceptable, as long as upgrading from one
version of boost to the other is low cost. If it requires too many
changes in the public interface of boost libs, or even worse, a change
of compiler, this becomes troublesome.

So, my opinion is that the choice is between :
- Support a compiler in boost until it is fully dead, burried,
worm-food, not even seable in museums
- Complexify the release processus, so that bug-fix releases of old
version become commonplace

I have no opinion about which of those options would be more time consuming.

Best regards,


Boost list run by bdawes at, gregod at, cpdaniel at, john at