How to maintain a release branch?
Hi I would be grateful for some advice on how to maintain a release branch. Suppose we create a release branch, finalise the work and make the release. We then maintain fixes for that release on that branch. Q1. As we apply fixes to the release branch, should we also manually apply those fixes to the trunk (where main development is proceeding)? Q2. Does there come a point when one should merger the release branch back into the trunk (or does Q1 imply that this is unnecessary because we have manually duplicated the changes in the trunk)? Q3. If we should merge the release branch back into the trunk, do we merge from trunk to release branch first (I guess not because that would pollute the branch)? Best regards David
Re: How to maintain a release branch?
On Mon, Nov 14, 2016 at 10:45:25AM +, David Aldrich wrote: > Hi > > I would be grateful for some advice on how to maintain a release branch. > > Suppose we create a release branch, finalise the work and make the release. > We then maintain fixes for that release on that branch. > > Q1. As we apply fixes to the release branch, should we also manually apply > those fixes to the trunk (where main development is proceeding)? > > Q2. Does there come a point when one should merger the release branch back > into the trunk (or does Q1 imply that this is unnecessary because we have > manually duplicated the changes in the trunk)? > > Q3. If we should merge the release branch back into the trunk, do we merge > from trunk to release branch first (I guess not because that would pollute > the branch)? > > Best regards > > David > Have you taken a look at how the Subversion project iself does this? The whole process is documented in these sections of the SVN project's Community Guide: "Subversion release process" http://subversion.apache.org/docs/community-guide/releasing.html#release-process "Creating and maintaining release branches" http://subversion.apache.org/docs/community-guide/releasing.html#release-branches It's a bit of a long read, and not all of this will be directly applicable to any given situation. But perhaps it can serve as a source of inspiration. Take a close look at how the STATUS file works, and the process around merging fixes to release branches. Note how our trunk is open for commits at any time without prior review, while the release branches are not. Consider how the STATUS file might as well be a ticket database, or a whiteboard on the wall. Some might prefer merging fixes from release branches to other branches and trunk, instead of from trunk to release branches. As long as merges are done by cherry-picking changes between branches, the direction of the merge really does not matter. Be careful about using trunk as a "stable" release branch and then also branching "feature branches" for development off of trunk at the same time. While it can be done, that approach does not tend to work very well with SVN. Putting releases on a dedicated release branch usually gives better results. This is different from how many other version control systems work, but is consistent with how people used to work with CVS (which SVN is a successor of). In any case, you'll need to be planning ahead and make sure every developer involved understands the process. Regards, Stefan
Re: How to maintain a release branch?
Hi David, On 11/14/2016 11:45 AM, David Aldrich wrote: Hi I would be grateful for some advice on how to maintain a release branch. Suppose we create a release branch, finalise the work and make the release. We then maintain fixes for that release on that branch. Q1. As we apply fixes to the release branch, should we also manually apply those fixes to the trunk (where main development is proceeding)? That depends on what's best for your process... In principle three common approaches work: a) you manually apply changes to trunk and the release branch b) you apply the fix to trunk and merge (cherry-pick) the related revision to the release branch c) you apply the fix to the release branch and backport it (via merge) to trunk (which can also be done in chunks at a given point We normally use approach b and have set up batch file which runs once per day to merge all flagged revisions (via a tag in the log message) which were committed to trunk to the release branch. Q2. Does there come a point when one should merger the release branch back into the trunk (or does Q1 imply that this is unnecessary because we have manually duplicated the changes in the trunk)? That heavily depends on your requirements. In general I don't see the need for that. One case where it would make sense would be if you also make changes to the release branch which you want to backported to trunk. Q3. If we should merge the release branch back into the trunk, do we merge from trunk to release branch first (I guess not because that would pollute the branch)? Only if you want all the changes in trunk to get merged into the release branch. Based on your description, I take it that's not what you want. Hence, the answer is no. -- Regards, Stefan Hett
RE: How to maintain a release branch?
Hi Stefan Thanks for your reply. > a) you manually apply changes to trunk and the release branch One thing I've never been sure of with svn is whether manually applying the same change (i.e. by edits not merges) on branch and trunk is a good idea. Can that result in conflicts when merging later? BR David > -Original Message- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: 14 November 2016 11:50 > To: users@subversion.apache.org > Subject: Re: How to maintain a release branch? > > Hi David, > On 11/14/2016 11:45 AM, David Aldrich wrote: > > Hi > > > > I would be grateful for some advice on how to maintain a release branch. > > > > Suppose we create a release branch, finalise the work and make the release. > We then maintain fixes for that release on that branch. > > > > Q1. As we apply fixes to the release branch, should we also manually apply > those fixes to the trunk (where main development is proceeding)? > That depends on what's best for your process... In principle three common > approaches work: > a) you manually apply changes to trunk and the release branch > b) you apply the fix to trunk and merge (cherry-pick) the related revision to > the > release branch > c) you apply the fix to the release branch and backport it (via merge) to > trunk > (which can also be done in chunks at a given point > > We normally use approach b and have set up batch file which runs once per > day to merge all flagged revisions (via a tag in the log message) which were > committed to trunk to the release branch. > > > Q2. Does there come a point when one should merger the release branch > back into the trunk (or does Q1 imply that this is unnecessary because we have > manually duplicated the changes in the trunk)? > That heavily depends on your requirements. In general I don't see the need for > that. One case where it would make sense would be if you also make changes > to the release branch which you want to backported to trunk. > > > Q3. If we should merge the release branch back into the trunk, do we merge > from trunk to release branch first (I guess not because that would pollute the > branch)? > Only if you want all the changes in trunk to get merged into the release > branch. Based on your description, I take it that's not what you want. > Hence, the answer is no. > > -- > Regards, > Stefan Hett > > > > Click > https://www.mailcontrol.com/sr/Vj6aNZznnVPGX2PQPOmvUjekYHk5lulQevXi > WVMqtR+Dmom+3B8m+QDuj+v!60mN2Cfu6uLF7dONc!rJiVGaJg== to report > this email as spam.
Re: How to maintain a release branch?
Hi David, On 11/14/2016 12:59 PM, David Aldrich wrote: Hi Stefan Thanks for your reply. a) you manually apply changes to trunk and the release branch One thing I've never been sure of with svn is whether manually applying the same change (i.e. by edits not merges) on branch and trunk is a good idea. Can that result in conflicts when merging later? Yes it can. But again this depends on the process. If you only apply the change in a file without really merging it, SVN won't add the marker flagging that change got merged already. Hence a following merge of that change (revision) will try to merge the change again. This can result in a conflict, if the lines close to the change are out of sync between the release branch and trunk. It won't cause a conflict, if the content of both files is the same. Certainly, if you use a proper merge, SVN won't try to merge the changes again and hence this scenario won't cause a conflict then. -- Regards, Stefan Hett
Re: How to maintain a release branch?
On Mon, Nov 14, 2016 at 6:59 AM, David Aldrich wrote: > Hi Stefan > > Thanks for your reply. > > > a) you manually apply changes to trunk and the release branch > > One thing I've never been sure of with svn is whether manually applying > the same change (i.e. by edits not merges) on branch and trunk is a good > idea. Can that result in conflicts when merging later? > Merge tracking does not have a huge impact on the actual merge, it has an impact on what revisions are merged. So in a release branch, I do not think it would make a lot of difference either way. The one scenario were merge tracking might yield fewer comments is if you use it to merge a revision(s) today and then later on you decide to merge everything (or an overlapping revision range). Merge tracking will make that followup merge smart enough to not re-merge the revisions you already merged. So that can help have fewer conflicts. But that is not a very common or normal scenario for a release branch. >From a pure documentation/history standpoint, I think it is better if you make the change on one branch and then merge it to the other. But technically speaking, merge is kind of just a fancy editor process to make the same changes to the same files. With the addition that it also creates some metadata about the merge that can be nice to have for your records keeping. -- Thanks Mark Phippard http://markphip.blogspot.com/
