Re: [boost] [BoostCon07][testing] Session reminder.

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