On Mon, Nov 14, 2016 at 10:45:25AM +0000, 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