Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <41588274.7080704@debrunners.com>
Date: Mon, 27 Sep 2004 14:13:24 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Branching for stable releases?
References: <413E2E8C.6070200@debrunners.com>
 <001901c49777$db7692a0$0200000a@lan>
 <09607C0D-03BE-11D9-A09C-003065905854@nonintuitive.com>
 <41487157.7090702@Sourcery.Org>
In-Reply-To: <41487157.7090702@Sourcery.Org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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