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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-07-01 01:37:22

On Mon, Jun 30, 2008 at 11:15 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>>
>> 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.
>
> Commentary by developers who deal with software releases of any form is very
> much welcome in these!
>

Thanks. :)

>>
>> On Mon, Jun 30, 2008 at 11:20 AM, Rene Rivera <grafikrobot_at_[hidden]>
>> wrote:
>>>
>>> David Abrahams wrote:
>>>>
>>>> James Sharpe wrote:
>
>> 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.
>
> Hm, I don't see how that follows. I can see the bottleneck authors time is,
> and is one of my main points. But I don't see how that follows to the
> problem of 'not-always-stable' trunk method.
>

The problem the not-always-stable trunk method brings in this
situation is where a fix that has to be made/applied to a library
that's already been released either goes first into trunk (because
trunk is not intended to be stable at all) then needs to wait for the
next release. Since the trunk is not always stable, you then encounter
the problem of having to maintain a different version of the libraries
in different branches -- a release 1.35, 1.34, 1.35.1, 1.36, etc. --
In case the trunk was always stable, then fixes that get applied to a
bugfix release can be merged into the trunk; then further development
of the library can happen in a private branch.

The unstable trunk also disallows the release manager(s) from simply
cutting a branch from trunk every-time a new release is to be made.
This exacerbates the problem because now instead of fixes that go into
the trunk that's intended to fix an issue in the release branch _for
the sole purpose of fixing bugs in that release branch_ will have to
be manually merged into the new release branch that was rooted on the
previous release version of the library.

So now you're faced with two issues:

1. The 'time-to-market' or 'time-to-release' of a fix that's intended
to address an issue in a release version gets longer and gets packaged
into a new major release.

2. The many versions of the library in supported major release version
and the many bug fixes that need to be tracked accordingly.

I'm not suggesting that we should start following the
'always-stable-trunk' method -- where we have a private branch named
'unstable' on which all breaking changes on a daily basis happen, and
on to which major changes in libraries have to be merged into before
being merged into the trunk after full regression testing. I'm rather
citing the difficulty of having authors working on private branches
then having to merge directly to trunk, and the release managers
having to cut branches from the last stable release instead of a
stable trunk and merging changes from the trunk done manually.

>> 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?
>
> Sure, but those are issues of convention only. The name itself is not
> important, just that we decide on a name. But deciding on a name is the
> least important aspect. The only option users have at this time is to diff
> from the tags/release/Boost_x_y_z (or from the archives directly).
>
>> 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?
>
> It could be named release_1_35, or release/Boost_1_35, etc. Hence the name
> is not important, just that it's agreed upon.
>

Okay. I guess then we just have to make that convention more 'formal' then?

>> What is the process of creating a release team for a bugfix release on
>> a major release?
>
> I would think the same as it is now for a regular release. Someone
> volunteers to be the release manager. And they ask for volunteers to help in
> the release, assuming they need help. And then they go through the same
> release process as for a regular release, just on a different branch and
> schedule.
>

Okay.

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