Merging to the release_1_6 branch
blair at orcaware.com
Wed May 28 10:17:02 PDT 2008
Rainer Müller wrote:
> 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,
Ideally you would fix the bug in trunk and then merge it to the release_1_7
branch which would appear in the next tagged release.
Going from the release branch back to trunk has two way merges and doesn't seem
as clean and easier to forget that a fix needs to go back to trunk.
More information about the macports-dev