Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-12 23:13:04

Beman Dawes wrote:
> The current approach to getting releases ready is completely broken in
> my opinion. Each release requires heroic efforts by the release manager,
> careful attention by many developers, and endless delays until
> everything is just right.

No doubt that the process is broken. I will say though, part of the
problem has always been nicely waiting for fixes to be made. Releases
could trivially be made by reverting any library with regressions to the
version in the previous build. This is similar to what you are
proposing, but would be more on the shoulders of the release manager to
be ruthless about meeting the deadlines. The current release, for
example, would be progressing much faster if we just took the obvious
position: v2 build system isn't stable enough, revert to v1 and move on.
v2 will be in the next release.

> This is discouraging to developers and, worse yet, important library
> upgrades and bug fixes are taking far too long to get into user's hands.
> The problems with the current release approach are not caused by release
> managers or developers, but rather by the release system itself. It just
> doesn't scale up to the number of libraries now in Boost, since every
> library has to be ready before a release can occur.

Again, it's mostly because the release managers are too nice. I'll
volunteer to be the next release manager, I'll set a date, and I'll
pretty much assure you that it will go out on or about that date because
I'd cut any change off that wasn't ready. One really good thing about
your proposal is that it builds in the fix it or you're reverted
expectation that has been lacking for so long.

> These problems will only grow worse as more libraries are added.
> I propose changing to a different release model, one based on always
> maintaining a release-ready stable branch and merging updates for
> individual libraries into it asynchronously.
> A draft proposal is available at
> I've put a fair amount of thought into this proposal, and have run some
> Subversion simulations to make sure it works smoothly.
> What do others think?

In general I like the direction. A couple concerns though:

1) This does mean additional work for developers since all changes will
require merges. So this better be really easy to do in SVN for the
trivial merges for an entire library. I still don't use SVN on a daily
basis, so it is hard for me to evaluate how much work merging will
require. Overall, however, it will be worth a little extra work to make
the release process actually work again...

I also wonder if there should be exceptions to this policy. For
example, a documentation update or example code not compiled as part of
regression test update. Putting these on the trunk will not provide any
feedback anyway. The only danger is that if you allow these exceptions
someone might get sloppy.

2) The dynamics of past releases have shown over and over that as good
as the regression system is unexpected things show up. So we either
need to tag a point where minor changes can be made to a release stable
point or freeze major changes on stable for a beta period while
beta-testers go one last step and test the packaged release. This is
mostly to avoid having to redo release notes, version numbers and other
work associated with the release.

3) Some core libraries need to be mercilessly reverted on the trunk as
well as on stable. There is a core set of libraries that cause major
issues when they don't work. type traits, config, and test come to
mind. If these libraries are unstable on the trunk they prevent other
developers from validating and moving their code to stable. Thus
developers of these libraries will need to be held to a higher standard
than developers of other libraries. They need to revert changes on the
trunk after some pre-defined period (48 hours maybe) if they can't fix a
build issue that is breaking lots of other libraries.

4) I suggest that the set of compilers monitored on the stable branch
will only be the group of agreed "supported compilers". If volunteers
want to add a new compiler to the supported set (say some new version of
the Sun compiler) they must demonstrate that a previous stable build of
Boost passes all libraries with no unmarked failures. It is up to these
volunteers to work with developers to achieve this state using the trunk.

Thx for doing this Beman -- it's something that really needs to be tackled.


Minor wording nits:

     * Regression tests are run daily on both trunk and stable. Testers
coordinate via the boost-test mailing list to ensure that both truck and
       Note well: Reverting is a safety-value only. Developers must never

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