[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Post 0.6.0 releases.
Re: Post 0.6.0 releases.
Fri, 06 Jun 2008 22:31:20 -0700
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
John Darrington <address@hidden> writes:
> 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
> > 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
Debian's stable (#1 above) and security fix (#2 above)
distributions, taken together, are equivalent to the proposed
PSPP branch #1 above. The changes between #1 and #2 are normally
very small, because Debian generally applies the minimal change
necessary to fix a security bug.
Debian's unstable distribution (#3 above, roughly) is somewhat
akin to the proposed PSPP branch #3 above: most packages in it
contain the newest release upstream version of software
(sometimes even unreleased versions from VCS).
I don't see anything equivalent to proposed PSPP branch #2.
That's the one that worries me.
> 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.
I don't see how branches in this scheme could ever merge. Many
changes that are appropriate for #2 will never be appropriate for
#1, and similarly many changes that are appropriate for #3 will
never be appropriate for #2 or #3.
I'm not worried about Git handling branching and merging. It
does both well.
Here is the branching model that I was envisioning maintaining at
- A bug fix branch for whatever is the current released
- An active development branch that contains whatever is
targeted to appear in the next released version of
- Additional experimental branches as necessary for
public and possibly collaborative long-term development
of big features that aren't ready for the active
development branch yet, one per feature. For example,
I'm assuming that the new output subsystem will be
developed this way. Eventually these branches get
merged back into the active development branch, if the
experiment is successful, and then discarded (although
the Git history shows that the branch was merged and
retains the branch history; that is, no information is
Maybe my vision for as-needed experimental branches is really the
same as your proposed branch #3?
In addition, I'll probably have half a dozen or so branches in
various stages of development going locally on my development
machine at any given time. Over at Nicira, I've probably had as
many as a dozen. Git makes it trivial to create, merge, and
discard branches, so it's my habit to use one per feature that
I'm working on. It appears that many Git users work this way.
"Long noun chains don't automatically imply security."
Post 0.6.0 releases., John Darrington, 2008/06/06
Branch topology [was Re: Post 0.6.0 releases.], John Darrington, 2008/06/13
Re: Branch topology, Ben Pfaff, 2008/06/14
Re: 0.6.0-rc1 available, Jason Stover, 2008/06/06
Re: 0.6.0-rc1 available, John Darrington, 2008/06/07
0.6.0-rc2 now available (was: 0.6.0-rc1 available), Ben Pfaff, 2008/06/08