Re: [boost] Proposal for radically altered approach to releases

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-05-17 11:18:24

"Nicola Musatti" <Nicola.Musatti_at_[hidden]> wrote in message 
news:loom.20060512T133243-385_at_post.gmane.org...
> Pedro Lamarão <pedro.lamarao <at> intersix.com.br> writes:
> [...]
>> Beman Dawes escreveu:
>>
>> "Formal releases occur on a regular schedule. The formal release
>> procedure is simply to package up the last tagged revision of stable,
>> publish release candidates, and decide if there are any issues serious
>> enough to wait for the next stable tag point."
>>
>> If this process would contemplate a bugfix branches associated with
>> stable tags, and if some backporting fixes effort were made, the people
>> complaining about API stability would be happier.
>
> I agree. In my opinion a new branch should be created on STABLE for each 
> formal
> release. Its main purpose would be to provide an escape should anything go 
> wrong
> with the formal release, but it would also be available for smaller scale
> bugfixing and backporting, subject to availability of necessary resources; 
> I'm
> aware that control should be exercised over what is committed on the 
> formal
> release branches, especially since these do not have an associated 
> "unstable"
> branch. People wishing to contribute to a bugfix branch should ensure that 
> a
> reasonable amount of regression testing is performed before the branch is 
> given
> a new "stable" tag.

With SVN, the distinction between a branch and a tag is blurred. They are 
both really just (virtual) copies at a given point in time. It is up to us 
exactly how we want to organize the releases we do.

If I understand you correctly, you are pointing out that sometimes we may 
want an explicit bugfix branch of STABLE rather than just moving on to the 
next week's STABLE tag point. We can certainly do that if useful. At this 
point, I'm not sure we want to try to micro-manage those future decisions. 
Rather, we can just make adjustments as we gain experience.

> Note that this would require a change in the release numbering scheme; a 
> couple
> of alternatives could be to add a fourth number for the weekly tags or to 
> just
> use the date in the YYYYMMDD format.

I thought of that, but decided to recommend keeping the initial scheme 
simple and a continuation of the current, familiar numbering scheme.

Thanks,

--Beman