To: gnu-arch-users@gnu.org
Subject: Re: [Gnu-arch-users] strategy to handle back-fixies
In-Reply-To: <20050124121855.GC22133@vandal.simcon-mt.de>
References: <20050120090735.GA18766@vandal.simcon-mt.de>
	<20050120200644.GA7715@vagabond>
	<20050121082757.GA19548@vandal.simcon-mt.de>
	<d6dy8en7yyt.fsf@twoflower.uio.no>
	<20050121133740.GG19548@vandal.simcon-mt.de>
	<41F11FF3.5020501@arbash-meinel.com>
	<20050124121855.GC22133@vandal.simcon-mt.de>
Mail-Folloup-To: never
Mail-Copies-To: never
Date: Mon, 24 Jan 2005 16:37:01 -0500
Message-Id: <20050124213701.BD5E91906F2@comet.merconline.com>
From: jblack@merconline.com (James Blackwell)
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 3072
Lines: 93
In lists.arch.users, you wrote:
> On Fri, Jan 21, 2005 at 09:29:55AM -0600, John A Meinel wrote:
> [...]
>> The only difference between what you said, and the recommendation, is 
>> the idea of keeping a "release" branch. Often, it is not good enough to 
>> know what the latest 1.0 version is (1.0.1, 1.0.2, etc). You need to be 
>> able to get a specific one. Customer Foo has installed 1.0.1, you've 
>> already done some work and are on 1.2, but you have also backported some 
>> fixes and have a 1.0.3 release.
> [...]
>
> Ok. After carefully studying everything I feel like I got things
> straight. (All sigh :) Really my proposal was also right, but kind of
> less convinient. I was going to create new branches for each release I
> did (including patch levels). Your proposal with release branch
> eliminates this, since patch level shall correspond with 'patch-1',
> 'patch-2' etc.

I generally use the following:

--dev--2.2

  patch-1
  patch-2
  patch-3
  ..
  patch-45 -\
             \-------candidate--2.2.2              (2.2.2 rc0)
  patch-46 _______/--patch-1                       (2.2.2 rc1)
  patch-47/        --patch-2 (reverse of patch-42) (2.2.2 rc2)
  patch-48       _---patch-3-
  patch-48      /            \
  patch-49-----/               --release--2.2.2   (releae 2.2.2)
  patch-50                   ----patch-1          (release2.2.2.1)
  patch-51 -----------------/
  patch-52/
  patch-53
  patch-54 --\
              \---candidate-2.2.3-
                                  \--release--2.2.3 (release 2.2.3)

This gives people several things: 

1. If they want the edge of development, they "get project--dev"
2. If they want the latest release, they "get project--release"
3. If they want the latest candidate, they "get project--candidate"
4. One can easily tell what's in what ("did this patch in dev get into
   a particular rc or release?") by comparing logs.
5. If its fixed in release then you know its fixed in -dev too.
6. Patch flow is loop resistant, as all patches flow in one direction,
   from dev -> candidate ->release. If a candidate is dead (release
   occurred), then from dev->release

Patch movement: 

* Patches into -dev are typically merges from the various developers for
  the project

* Fixes in candidates and releases are either simple replays or
  reverses.


>
> Ok. Thanks for your help. 
>
> -- 
> Minds, like parachutes, function best when open
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> Gnu-arch-users@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/