Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-03-08 11:15:59


At 09:23 AM 3/8/2001 -0600, Todd Greer wrote:

>I'm starting to push the use of boost where I work, and I'm trying to
>figure out how I should decide when to get updates, what versions I
>will need to keep locally available even after more updates, and such
>logistical issues. I would very much appreciate insight into how and
>when new releases are made. Does a minor release promise no
>incompatible changes? Is there a convention regarding version
>numbers? Is anything allowed into boost_all.zip before it's
>well-tested and stable? Is there some place I could have found this
>information without needing to ask? I need to know these sorts of
>things to control versions of boost used in our commercial products.
>
>I suspect that this sort of information should be on the web site
>somewhere, but I couldn't find any such information.

I'll add these to the FAQ:

What do the Boost version numbers mean?

The scheme is x.y.z, where x is incremented only for massive changes, such
as a reorganization of many libraries, y is incremented whenever a new
library is added, and z is incremented for maintenance releases. y and z
are reset to 0 if the value to the left changes.

How can the Boost libraries be used successfully for important projects?

Many of the Boost libraries are actively maintained and improved, so
backward compatibility with prior version isn't always possible. Deal with
this by freezing the version of the Boost libraries used by your
project. Only upgrade at points in your project's life cycle where a bit
of change will not cause problems. Individual bug fixes can always be
obtained from the CVS repository.

Comments?

>Boost has some great stuff, and I just need a little information
>before I can bring it to our multitude of development efforts, some of
>which share varying amounts of code, most of which have independant
>release schedules.

Hope the above helps a bit. Thanks for the questions!

--Beman


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