[Top][All Lists]

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

Re: Post 0.6.0 releases.

From: Ben Pfaff
Subject: Re: Post 0.6.0 releases.
Date: Mon, 09 Jun 2008 09:05:10 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Ben Pfaff <address@hidden> writes:

> John Darrington <address@hidden> writes:
>> On Fri, Jun 06, 2008 at 09:39:04AM -0700, Ben Pfaff wrote:
>>      John Darrington <address@hidden> writes:
>>      > 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.
>> 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.

Upon reflection, I think you must have meant merging in the other
direction: fixes from #1 merged into #2 and #3, and enhancements
from #2 merged into #3.  That makes sense.
"The fact is, technical people are better off not looking at patents. If
 you don't know what they cover and where they are, you won't be knowingly
 infringing on them. If somebody sues you, you change the algorithm or you
 just hire a hit-man to whack the stupid git." --Linus Torvalds

reply via email to

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