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
Received on 2016-11-14 12:35:03 CET