On Tue, Apr 14, 2009 at 10:16 AM, Noah Slater <[email protected]> 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, http://tumbolia.org/nslater > -- Chris Anderson http://jchrisa.net http://couch.io
