On Apr 14, 2009, at 2:09 PM, Chris Anderson wrote:
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.
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.
-Damien
