From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-03 14:03:26
"Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message
> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
> [snipped lots of sensible stuff]
>> VI Boost release
>> The boost release is done automatically every predefined period of time
>> (like three month). It requires NO testing, NO branching and NO
>> merging/reverting. It's done by single script (a bit oversimplification,
>> close) that does these tasks:
>> 1. It iterates through all components and check any component that was
>> released since previous boost release.
>> Very important: The component should NOT depend on older version of
>> component that is being released. For example if library A depends on
>> version 1.23 of library B and version 1.24 of library B was released,
>> library A won't become part of the next boost release.
> Here I don't understand. Suppose Boost release X contains library A
> 1.4, and library B version 1.23, and library A depends on library B. The
> developer of library B then releases a new version (1.24), and the author
> library A doesn't. The next Boost release (Y) comes along, and now library
> is no longer part of the Boost release? That strikes me as a bad plan ---
> contents of Boost will vary from release to release as developers update
> libraries at different rates.
> As an alternative, how about this: if library A depends on version xyz of
> library B, then library B is pinned at version xyz for Boost releases
> library A is updated. If library A is not updated for n consecutive Boost
> releases, library A is dropped from Boost as unmaintained.
Hmm. All good points. How about this:
a) library A depends on concrete version xyz of library B
b) B is released library
c) library A is not updated
library A indeed in this case is not included, since it's intentionally
points to the particular release of library B that is not included in new
version ob boost anymore.
2. If library A depends on LATEST version of library.
As soon as B is released, library A regression test will have to be resumed
also (according to the procedure). If by the time we are ready to release
boost library A regression is all green we do "automatic
promotion/patching". We release patch version of library A that now depends
on newly released library B. This process can be automatic.
If regression failures are present we do need to postpone library B
inclusion into boost release. Library B released in automatically made "not
> How about this, also: a library developer can only release their library
> if it
> is built against the latest released version of all its dependent
> libraries. That way if a core library is updated, all other libraries will
> have to use the new version before they can release.
No. I do not wont to restrict developers in how they do their development
and what version they depend on. If you opt to depend on concrete version of
the library B you need to understand the consequences: If B is released, you
will have to do your own release manually or your library is not included in
umbrella boost release.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk