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

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

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.

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

If you assume we're switching on every release cycle, people will be
used to doing it, or there's at least a good chance it will be automated
(c'mon, that's _trivial_ by comparison to many of the things we do for
testing!) whereas if testers have to manually switch in order to test a
point release there will be mayhem by comparison.

> It would be the responsibility
> of a 1.35.1 release team to coordinate with testers, for that release,
> the branch to test and test resources to devote specifically to it.

Sounds like a plan without a plan.

> [stuff about version control]
> 
> It is counter productive to think that a new version control system is
> going to solve such testing and release problems. If we can't manage the
> release process with the tools we have we have no hope of ever
> succeeding in creating a stable release process.
>
> I know, I may be sounding bitter at this point... But I'm a pragmatist
> at heart and trying to solve things with fresh new toys rubs me the
> wrong way since I've seen the tactic fail repeatedly.

What gave you the idea that I was suggesting we use a new VC system?

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