couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Backporting bug fixes to 0.9
Date Tue, 14 Apr 2009 18:09:40 GMT
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.

> --
> Noah Slater,

Chris Anderson

View raw message