couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Lucy <simon.l...@objective2k.com>
Subject Re: Backporting bug fixes to 0.9
Date Tue, 14 Apr 2009 17:13:03 GMT
Noah Slater wrote:
> Hello,
>
> I've just been working through the 0.9.x cherry picking and I would like to
> propose a change to the formal release procedure. I have followed the
> instructions bellow for my own changes. You will find there 15 outstanding
> revisions that need to be checked before we can release.
>
> You can find the existing release policy here:
>
>   http://wiki.apache.org/couchdb/Release_procedure
>
> My proposed changes are as follows:
>
> Before releasing a new tag from the maintenance branch branches/Y.Y.x all
> available revisions from trunk must have been merged or blocked. You can get a
> list of all outstanding revisions by running the following command:
>
>   svn mergeinfo trunk branches/Y.Y.x --show-revs eligible
>
> You can inspect each revision log with:
>
>   svn log -r REVISION
>
> You can inspect each revision diff with:
>
>   svn diff -c REVISION trunk branches/Y.Y.x
>
> If you don't want to cherry pick a certain revision, you must block it. This is
> a way of instructing Subversion that the revision is not eligible for merging.
> You can block a revision by running the following commands:
>
>   svn merge -c REVISION --record-only trunk branches/Y.Y.x
>
>   svn commit branches/Y.Y.x -m "blocked REVISION from trunk"
>
> If you want to cherry pick a certain revision, you must merge it. When you merge
> a revision, Subversion makes a note so that it is no longer listed as being
> eligible for merging. You can merge a revision by running the following command:
>
>   svn merge -c REVISION trunk branches/Y.Y.x
>
>   svn commit branches/Y.Y.x -m "merged REVISION from trunk"
>
> Once this has been completed, there should be no revisions listed as being
> eligible for merging. The only time a release tag should be cut from a
> maintenance branch is when there are no eligible revisions for merging. This
> policy ensures that all changes have been properly reviewed before a release.
>   
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.

S

> Best,
>
>   


Mime
View raw message