Re: Post 0.6.0 releases.

[Ben Pfaff]

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

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

        - A bug fix branch for whatever is the current released
          version.

        - An active development branch that contains whatever is
          targeted to appear in the next released version of
          PSPP.

        - 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
          lost).

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."
--Bruce Schneier