"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. 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. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL