Branching for stable releases?

[Daniel John Debrunner <dj...@debrunners.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Apache DB guidelines has this section on branches

[quote]
Branches
Groups are allowed to create a branch for release cycles, etc. They are
expected to merge completely back with the main branch as soon as their
release cycle is complete. All branches currently in use should be
documented by the respective projects.
[end-quote]
[http://db.apache.org/source.html]

I read that to mean that the branch only exists during the release
process. I'm not sure that this works well for Derby.

Say the upcoming release for Derby is released successfully. After that,
assume some feature work is committed into the single Derby codeline
(trunk).

Now, some user of that release finds a bug and provides a fix (or
someone else does). If there is only a single codeline then there are
three issues:

  1) the upgrade code to support the user's release may not be working,
as the latest codeline is not in a release state. Thus the user cannot
fix their problem.

  2) the codeline contains features and code the user is not interested
in and may concern them. From my experience, database users want the
minimum amount of changes in any bug-fix release for fear of
destabilisation of the code.

  3) the codeline may be broken (hopefully not, but a small
possibility), thus not allowing the user to build a version that works
easily.

One solution is to lets users build their own bug fix versions, based
upon the initial code version and merges of various bug fixes. This can
be time consuming for each customer and subject to mistakes (say a fix
is omitted accidentally, regressing their version).


Another solution is to maintain a stable branch after a release. All
subsequent bug-fixes and releases of that stable line are made in that
branch. This stable branch would typically only have bug fixes applied
to it, changes that require some upgrade would typically not be
accepted. The main trunk continues to be the only development line.
This addresses 1), 2) and 3) above, well with 3) it just reduces the
possibility the codeline is broken as the complexity of the changes is
hopefully smaller.

The downside here is that fixes may have to be merged between multiple
branches, the release branches and the development trunk. Another
downside is the number of branches, which depends on the frequency of
new releases from the development codeline.

With a community it may work out that those users of the releases
corresponding to the branches will maintain the branch. E.g. if they see
a bug being fixed in the trunk, they will move it into a branch if they
think it is suitable.


Do folks think stable branches or a single trunk line is the way to go?

Any other potential solutions?

Dan.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBWIJzIv0S4qsbfuQRAsySAJwJKSlW2sqFsKrRlS+NxaAPjfC9OgCePL3a
6r2x/2NyplQfDFXM8dEs05o=
=Z3hx
-----END PGP SIGNATURE-----

Re: Branching for stable releases?

[Daniel John Debrunner <dj...@debrunners.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John McNally wrote:

> Daniel John Debrunner wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The Apache DB guidelines has this section on branches
>>
>> [quote]
>> Branches
>> Groups are allowed to create a branch for release cycles, etc. They are
>> expected to merge completely back with the main branch as soon as their
>> release cycle is complete. All branches currently in use should be
>> documented by the respective projects.
>> [end-quote]
>> [http://db.apache.org/source.html]
>>
>> I read that to mean that the branch only exists during the release
>> process. I'm not sure that this works well for Derby.
>>
>>
>
> You interpretation may be correct, but that would only mean the document
> should be better written.  The only way I think it would be a valid
> statement if it is interpreted as "all applicable patches committed to
> the release branch should be ported to the trunk".  It makes sense to
> leave a release branch available for quick updates for severe bugs or
> security issues.
> John McNally
>

So I think we have lazy approval to use stable/release branches as
described by John and myself.

Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBYCGqIv0S4qsbfuQRAqIpAJ9PDgmCjWKxr7ATejqubyPwSMYCgwCfZ6aw
GM+5a5pMHEYPQ2cSSNYMSIU=
=4IQb
-----END PGP SIGNATURE-----

Re: Branching for stable releases?

[John McNally <jm...@collab.net>]

Daniel John Debrunner wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>The Apache DB guidelines has this section on branches
>
>[quote]
>Branches
>Groups are allowed to create a branch for release cycles, etc. They are
>expected to merge completely back with the main branch as soon as their
>release cycle is complete. All branches currently in use should be
>documented by the respective projects.
>[end-quote]
>[http://db.apache.org/source.html]
>
>I read that to mean that the branch only exists during the release
>process. I'm not sure that this works well for Derby.
>  
>

You interpretation may be correct, but that would only mean the document 
should be better written.  The only way I think it would be a valid 
statement if it is interpreted as "all applicable patches committed to 
the release branch should be ported to the trunk".  It makes sense to 
leave a release branch available for quick updates for severe bugs or 
security issues. 

John McNally

RE: Branching for stable releases?

["Noel J. Bergman" <no...@devtech.com>]

Daniel John Debrunner wrote:
> The Apache DB guidelines has this section on branches

> I read that to mean that the branch only exists during the
> release process. I'm not sure that this works well for Derby.

I'm not sure that it works well, period.  For example, a developer who is
going down an experimental development path can maintain a branch in SVN,
rather than (as we've often seen in the past), work in isolation, and only
check in when finished.

It makes sense to create a branch when doing a release, so that you can
manage what will be in that branch without impacting trunk development.  And
when you're done, you can copy the branch as a tag, thus fixing in time the
release, as well as leaving in place a branch for maintenance.

I have no idea what the DB PMC had in mind, but you can ask them.  They are
part of your Derby PPMC, since they are sponsoring the project.  The Derby
PPMC can make the decision as to how to manage the code.

	--- Noel