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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-06-29 23:44:05

Sorry to jump in here... Not being a Boost author myself makes this a
little awkward, but I'd like to get my $0.02 worth in there.

On Mon, Jun 30, 2008 at 11:20 AM, Rene Rivera <grafikrobot_at_[hidden]> 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. And the content is
> exactly the same currently. 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. Then it is as simple as always creating a new branch for each major
> release at then *end* of said major release.
>

I think the diversion here comes from the fact that only authors (or
maintainers) are able to check in code to the subversion repository --
and patches that go towards a 'bugfix point release' need to go
through the authors/maintainers. This is a problem of the
'not-always-stable' trunk paradigm, where major/minor development
happens on the trunk which gets tested day by day.

Not having the name right is a problem: say for example I as a user of
the library would like to contribute a patch to a release version that
addresses a particular bug *in that release*. Not knowing from which
subversion branch to diff from or create a patch from *is* an issue.
For example, when 1.36 comes out and we're still supporting the 1.35
release, how do I patch the 1.35 release to create a 1.35.1 release
and so on for particular libraries in that release?

Another is the fact that the convention for a bugfix release has not
yet been solidified since the idea of a quarterly release has been
proposed or put into motion. Somehow we'll need to address how the
bugfix release can be done with little or no friction with the
continued development of the major release(s). Bugfix releases
shouldn't follow a schedule (like how the major releases do) because
there may be changes that are immediate that need to be pushed as a
point-release. Not only that, having this facility allows users
(enterprises?) to standardize on a release and just update when that
particular release does a point-release. Sometimes these users would
like to stick to a release that has been tested internally by them
which contains only the set of libraries in that particular release;
when they find a bug, it's really unreasonable to expect them to
upgrade to a new major release with potentially breaking changes to
existing libraries and have to wait for a scheduled release to do
this.

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

So how then would a 1.35.1 release team continue to patch things up in
1.35.0 if the release branch for that release isn't named
release_1_35_0?

What is the process of creating a release team for a bugfix release on
a major release?

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

I agree. I think it's more about making the process clear-cut with
less distractions; If somehow we set these down in a manner that makes
sense and pleases the authors/maintainers more than it does 'just
users' then we should be able to get to a situation where we would
know precisely what to do when certain things come up -- like the need
for a bugfix release.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.