Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-15 15:32:56


From: "AlisdairM" <alisdair.meredith_at_[hidden]>
>
> Personally I find adding libraries in a minor release to be confusing -
> I expect a minor version essentially to be patching bugs, rather than
> adding features.

That's not how most software handles version numbers.
Applications regularly add features in minor version upgrades.
Dramatic additions of functionality or reworking of existing
functionality normally indicate a major version number bump.

Patches usually only address bugs, security issues, etc.

> I would be in favour of shorter release cycles though, as new libraries
> come through the review queue. Regular releases like this would
> probably keep the mainline more stable avoid some of the problems seen
> trying to get the last 2 releases out the door.

That's come up before. The question is how to effect it.
Library developers need some time to insert new functionality and
changes to existing functionality between releases. When that
happens with multitudinous libraries, the compounding of problems
leads to long release cycles.

The only thing I can think of to address this is for each library
to have its own branch for development. Then, when it is deemed
ready, that branch is promoted to an integration branch. If it
fails there, the promotion is rolled back until the library is
changed, gets required changes in another library, etc.
Eventually, all libraries compile and test fine in the
integration branch and the whole set can be promoted to a release
branch.

IOW, promotion for integration should be happening throughout the
year, but only when a given library is ready to do so. A release
is nothing more than taking a timely snapshot of the integration
branch. That also means that those that don't want bleeding edge
changes, but want more than was in the last release, can get the
latest integrated set of libraries from the integration branch.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

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