From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-03 14:03:26
"Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message
news:ejlxj095.fsf_at_yahoo.com...
> "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,
>> but
>> 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
> version
> 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
> of
> library A doesn't. The next Boost release (Y) comes along, and now library
> A
> is no longer part of the Boost release? That strikes me as a bad plan ---
> the
> contents of Boost will vary from release to release as developers update
> their
> 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
> until
> 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:
1. If
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
LATEST".
> 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.
Gennadiy