Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-11 11:38:17


This is on the right track.

Not too long ago we had a discussion of this very topic
a few months ago.

see http://lists.boost.org/Archives/boost/2006/01/99522.php

I made specific proposal similar -but different- to what you're doing here.
I failed to make a convincing case for it. I let it rest because I knew
that sooner or later
the case for it would become more obvious. I see that happening
now. I confess that I thought the current process would last
at least one more release before breaking down so I was
wrong about that.

Robert Ramey

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.
>
> 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.
>
> 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
> http://mysite.verizon.net/beman/release_overview.html.
>
> 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?
>
> --Beman
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


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