Hi, I think that if we want to make sure that the release branches we created for Axis2, Rampart and Sandesha2 remain usable to do maintenance releases, we need to agree on a couple of guidelines about how to manage these branches. Based on my experience from the (quite successful) 1.5.x releases, here is what I propose as guidelines:
1. Always apply changes to the trunk before merging them to the branch (taking into account the obvious exceptions such as changing versions of dependencies). Rationale: (a) since there are more changes on the trunk, it is easier to resolve conflicts when merging from trunk to branch instead of the other direction; (b) experience shows that people tend to forget to merge when doing the change on the branch first (leaving the cleanup work to others). Examples for (b): * r1054918 was applied to the Rampart 1.5 branch more than a month ago, but never applied to the trunk. When creating the Rampart 1.6 branch, I ran into the very same issue that this commit solves. * For more than a year, the HTTP connection management changes only existed on the 1.5 branch. When they were finally reintegrated into the trunk, that caused lot of confusion and discussions. * When Ruwan did the first Axis2 Transports release, he did lots of improvements to the Maven site, but forgot to apply them to the trunk. It would have been very sad if we had lost these improvements. 2. Make sure that we keep track of what has been merged to the branch. Subversion now (I think since version 1.5) has an integrated feature that records merges. You only need to use an appropriate tool that supports this feature. With the command line client, this is fairly easy. Assuming that "axis2" is a working copy of the trunk and "axis2-1.6" a working copy of the branch, just do (<revision> is the revision number of the original change on the trunk): svn merge -c <revision> axis2 axis2-1.6 After that, review the changes in axis2-1.6 and commit them. This will update the svn:mergeinfo properties to record the merged revision. Note that I've cleaned up the metadata on the trunk and the 1.6 branch, so that we will no longer get the insane amount of property changes that we saw on the 1.5 branch. 3. Take merge conflicts seriously. Subversion knows what it does, so if "svn merge" reports a conflict, then there is a good reason for that. If unsure why a given change can't be merged, just ask on the mailing list for help. 4. Never ever think about applying a change to the branch by copying files from the trunk. You will eventually end up applying changes to the branch that you didn't intent to apply, and this is very hard to detect. Also, I think it is useful to recall a couple of other best practices that make work easier for everybody: * When committing a change related to a JIRA issue, always include the issue number (including the prefix) in the log message. This allows JIRA (and other tools) to link the commit to the issue report. When applying a change to the trunk and to the branch, both commit messages should contain the issue number. * When resolving a JIRA issue, update the "Fix Version" field appropriately. Don't use "nightly" for that because after a couple of months, "nightly" is no longer meaningful (because in the meantime the change will have been included in a release). Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org
