From: Christopher Currie (christopher_at_[hidden])
Date: 2004-01-09 18:21:24
Joel de Guzman wrote:
> I think we should start to discuss the possibility of having individual
> releases (as Spirit is doing right now) instead of one monolithic release.
Apparently a lot of people have strong feelings one way or another on
this one. From my perspective, it seems a lot of time is spent by the
release managers hounding library developers to get their last minute
fixes in at release time.
It's of course too late for 1.31, but how about a comprimise? This is
going to be hard to describe, but bear with me:
* When a library's owners deem that they their library has a enough new
features to justify a new release, they assign an appropriate version
number, tag/branch CVS, and bundle up a tarball that can be unpacked on
top of the most recently released Boost tarball.
* Boost release managers set a cutoff date: any libraries who want
updated code in a new combined Boost release *must* perform their own
release prior to the cutoff date, say 1 month before release.
* Branch for release, do final platform testing, working with library
owners to get bugfixes in.
* Tag and release, with a statement like "This release of Boost
incorporates Boost.Filesystem x.y, Boost.Thread v.w, etc..."
* Repeat every 3, 4, 6, or 12 months.
If properly managed, it could be a best of both worlds. Booot release
managers no longer question if a library is ready for a new release,
because it's already happened. Libraries have a way of getting new
features out without waiting a big release, and of ensuring that a
release won't pick up code that's not ready for primetime.
It's not perfect; and sometimes maybe no one has released a library
since the last combined release, so we'd skip a cycle. But at least
incremental releases could get out new features without having to wait
for other libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk