[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Post 0.6.0 releases.

From: John Darrington
Subject: Re: Post 0.6.0 releases.
Date: Sat, 7 Jun 2008 09:22:55 +0800
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Fri, Jun 06, 2008 at 09:39:04AM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     > On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
     >      After the release, I want to try to get out bug-fix releases, at
     >      least, on a more frequent basis than we've been doing.  Let's see
     >      how that goes.
     > I suggest that we maintain three branches.
     > 1. A branch containing the current release patched with  bug-fixes.
     > 2. A branch containing 1 (above) patched with enhancements.
     >    "Enhancements" in this context means  changes which provide new
     >    functionality without requiring major code reorganisation.  Eg new
     >    commands which don't require low level library modification.
     > 3. A branch containing 2. patched with any changes which don't fit
     >    the above criteria.
     Is there some existing project that uses a similar scheme?  I am
     familiar with projects that have a bug fix-only branch and a
     development branch, but I am a little concerned that maintaining
     both #2 and #3 could cause a lot of extra work.

Well Debian uses a very similar system:

1. The current release.

2. The current release + fixes for security related bugs.

3. The current release + fixes for security related bugs + other

Obviously, more branches means more work.  How much extra work depends
on how much the branches overlap, how often they're merged and how
well git has been designed to handle branches.


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]