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

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-30 16:06:10

Beman Dawes wrote:
> 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.

If you're suggesting that we consider some snapshot of branches/release
to be a point release of each officially released version, then that
won't fly at all.  One of the main reasons people want a point release
is so they can be sure they're accepting only minimal changes to the
release they're working on: just bug fixes and that's _it_.

>>>> 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.

But you don't need to, as has been pointed out many times.  Just use an
svn:externals to cause a copy of the current release branch to be found
under the same name.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com