"Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message news:ejlxj095.fsf@yahoo.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> 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