couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Backporting bug fixes to 0.9
Date Tue, 14 Apr 2009 18:16:47 GMT

On Apr 14, 2009, at 2:09 PM, Chris Anderson wrote:

> On Tue, Apr 14, 2009 at 10:16 AM, Noah Slater <>  
> wrote:
>> On Tue, Apr 14, 2009 at 06:13:03PM +0100, Simon Lucy wrote:
>>> This implies that all development on trunk is targetted at that  
>>> release,
>>> is that actually true?  Different projects have different branching
>>> rules, I cleave to the unstable trunk, stable branch myself which  
>>> means
>>> that trunk continues ever onward.  In that scenario you don't  block
>>> revisions unless its explicitly known that they shouldn't be  
>>> taken.  I
>>> wouldn't use block as an admin process.
>> Well, my thinking is that this only applies to the most recent  
>> maintenance
>> branch as that would only have a few revisions to check against.  
>> But there is
>> the possibility that we would want to make a security release of a  
>> much older
>> maintenance branch which would be very problematic.
>> That pretty much blows a hole in my entire proposal!
>> Any other suggestions for some advisory policy change incorporating  
>> this work?
> Thanks for the cherry-picking command examples!
> Maybe it's best (as you mentioned earlier) to make this happen at
> commit-time. When you commit a revision, merge it to the current
> version branch, unless it's inappropriate to do so. Then the release
> procedure could consist of double-checking the eligible revs list to
> be sure nothing fell through the cracks.

I think generally we shouldn't backport fixes unless we have a good  
reason to. The point of release branches is stability, unless the bug  
is serious, the branch should remain as is. The longer the branch has  
been released, the higher the bar for backporting fixes.


View raw message