Merging to the release_1_6 branch

Rainer Müller raimue at
Tue May 27 23:52:16 PDT 2008

Joshua Root wrote:
> I would have no objection to tagging trunk today and calling it an -rc1. 
> Well, except that there are apparently some bug fixes in the 1.6 branch 
> that are not in trunk - argh!

But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where do 
you fix a bug found in that rc1? On and trunk and you merge it back to 
the 1.7.x release branch. So you definitely need a 1.7.x branch and 
there is no way to make that from trunk as it could get other changes in 
the mean time which are not suited for a release. If we would not make a 
release branch as suggested by Jordan and make the release from trunk, 
trunk would have to go into code freeze until the final release is there.

So if a release was near, I would do (with some pseudo-shell commands):
   svn cp trunk branches/release_1_7
   svn cp branches/release_1_7 tags/release_1_7_0-rc1

Bug fixes go to branches/release_1_7. Anything can happen on trunk in 
the mean time. If the release candidate was considered bug free,
   svn cp branches/release_1_7 tags/release_1_7_0
And then release from that tag.

This is how it should be done in my opinion, if I was any unclear in my 
previous explanations. And I think this is also the way we do it 
already, except the fact that some new features were merged back to 
release_1_6. Why did this happen? Because nobody watches the merges or 
it is not clear who does the merging at all.

And now please back to my initial question.


More information about the macports-dev mailing list