For my company, we do the following. For externals, use the pegging format We copy every release to our releases branch https://XXX/svn/releases/major.minor.svnrev
For released bugs, that are to be fixed via patch release, the policy is to fix it on the branch and then merge it to trunk. When this is done, merging is pretty easy However, this sometimes gets forgotten, and the fix is done on top of trunk, and then merge the specific revision onto the release. This flow tends to cause conflicts overall. Where this breaks down, is when some form of code change has occurred on trunk, that forces the fix to be done differently between the release and trunk.. This causes problems, and the question has to be asked, how critical is the bug for the patch. For Q2,the ONLY time code is NOT merged from the release to trunk, is when the issue has been fixed in a different manner Q3) we don't merge from tot "blindly" only specific and targeted revisions.. otherwise we just create a new release branch from the current tot Scott -----Original Message----- From: David Aldrich [mailto:david.aldr...@emea.nec.com] Sent: Monday, November 14, 2016 2:45 AM To: 'users@subversion.apache.org' (users@subversion.apache.org) <users@subversion.apache.org> Subject: 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
