Re: [boost] A branching/tagging idea for releases

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-06-30 16:01:52

David Abrahams wrote:
> Rene Rivera wrote:
>> David Abrahams wrote:
>>> James Sharpe wrote:
>>>> What we gain is the ability to be making bug fix releases of previous
>>>> versions whilst working on the next release. With the current system
>>>> there is no way of doing this simultaneously, if we want a bug fix
>>>> release, which I'd suggest should happen, given the demand we've seen
>>>> on the list, we need a method of doing so.
>>> I 100% agree with that.
>> Some people keep saying that. But I fail to see how the current setup
>> prevents one from doing this. The name of the branches & tags is
>> irrelevant. They are just names! It's the content that matters.
> 
> Exactly.
> 
>> And the content is exactly the same currently. 
> 
> The same as what?
> 
>> If there is a *release team* for
>> doing a 1.35.1 release. It is their responsibility to create the branch
>> for them to work on such a release. If it is a matter of policy that we
>> want to add to the workload for library authors and maintain point
>> releases on an ongoing basis. 
> 
> Surely you don't think the purpose of doing a point release is to add to
> the workload for library authors?  The point is to serve users who
> aren't prepared to accept a new major revision with all the
> incompatibilities that may entail, but who need bugfixes.
> 
>> Then it is as simple as always creating a new branch for each major
>> release at then *end* of said major release.
> 
> That could work too.  As long as there's a way to handle it, that's fine
> with me.  As it stands today, when a library author finds a bug that
> ought to be fixed in the next point release (should we decide to make
> one) there's no place for him to check the fix in that will guarantee
> that it goes into the point release.

What's wrong with branches/release as the location of the point release? 
Presumably developers are merging fixes there anyhow, it is being 
tested, inspected, and release files being built on a daily basis.

> 
>>> Of course, having testers operate on a single branch called "release,"
>>> no matter how we do it, is really incompatible with the idea of testing
>>> point releases concurrently with other releases.
>> I don't remember where anyone said we would have only *one* tested
>> branch. Just that it would be more work on testers to have to switch on
>> each release cycle the branch they test.

That just doesn't work in practice. Having to beg, plead, and pester 
testers to switch isn't a workable solution.

--Beman