Boost logo

Boost :

From: Phil Richards (news_at_[hidden])
Date: 2006-02-03 09:22:17


On Wed, 01 Feb 2006 13:50:58 -0800, Robert Ramey wrote:
> Sebastian Redl wrote:
>> Robert Ramey wrote:
>>> If the HEAD is always maintained in "releaseable" state you won't want
>>> to do such a thing. Of course you could branch from a previous version
>>> - but in practice I wouldn't expect one to want to.
>> I would. Especially if you're going to stop support for old compilers,
>> you will want a releasable branch for each of the old Boost versions
>> that were the last to support a specific compiler.
[...minor snip...]
>> I think this is a prerequisite to
>> dropping support for compilers that still are in use, like VC6.
> OK in that case you would - but we're not doing any of that now.

Well, how many compilers have been deprecated/stopped being supported by
boost in the last few years? Certainly none of the "big" ones. So, this
process hasn't been needed until now.

I agree completely with Sebastian - create support branches on the last
release that supports any specific compiler. Backport *significant* bug
fixes as required.

Do this for as long as there is somebody who actually cares enough to
organise testing/releasing of that version (and obviously it only needs to
be tested/maintained for those compilers that the branch exists to
support).

Personally, I see no need to deprecate a compiler for a whole release -
what good does it serve? I think there is general acceptance that new
libraries wouldn't *need* to work against deprecated compilers, so it is
quite possible that the next release after the "deprecation release" will
contain no new libraries for the compiler anyway.

As long as there is a clear list on a downloads page which indicates
what release to do download for which compilers, that is surely
sufficient... isn't it? (Oh, and I suspect that keeping a copy of the
"old docs" around might well be desirable.)

phil

-- 
change name before "@" to "phil" for email

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk