subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <>
Subject Re: How to maintain a release branch?
Date Mon, 14 Nov 2016 11:34:10 GMT
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"

"Creating and maintaining 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.


View raw message