+1 I think this is a candidate for a set of developer resources, including the release process guide too. I have some comments related to that which I will share shortly.
Regarding the Axis2 transports, yes due to the release pressure I forgot to commit the changes to the transports trunk. I was having the Synapse release to follow that transports releases too. Anyway that is no an excuse :-) I think we should link this somehow from the release guide too so that we can make sure we do not forget to commit them back to trunk. Thanks, Ruwan On Sat, Feb 19, 2011 at 10:19 PM, Andreas Veithen <andreas.veit...@gmail.com > wrote: > 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 > > -- Ruwan Linton Member, Apache Software Foundation; http://www.apache.org <http://wso2.org> phone: +94 11 282 7532 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
