[ https://issues.apache.org/jira/browse/HADOOP-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484768 ]
Tom White commented on HADOOP-1161: ----------------------------------- Apache ActiveMQ seem to have a good system for branching and merging (http://activemq.apache.org/source.html). In brief: * Use trunk for main development. * Create a branch for each major release. * Apply changes to trunk first, then backport into branches later. They even have a little script to help with the backporting (https://svn.apache.org/repos/asf/activemq/scripts/activemq-backport.sh). Re: Owen's worry about accidental leakage of new features into the stable branch - I think this could be alleviated by not mixing bug fixes and feature improvements in the same Jira issue/patch. > need improved release process > ----------------------------- > > Key: HADOOP-1161 > URL: https://issues.apache.org/jira/browse/HADOOP-1161 > Project: Hadoop > Issue Type: Improvement > Components: build > Reporter: Doug Cutting > Fix For: 0.13.0 > > > Hadoop's release process needs improvement. We should better ensure that > releases are stable, not releasing versions that have not been proven stable > on large clusters, and we should better observe Apache's release procedures. > Once agreed on, this process should be documented in > http://wiki.apache.org/lucene-hadoop/HowToRelease. > Here's a proposal: > . candidate release builds should be placed in > lucene.apache.org/hadoop/dev/dist > . candidate artifacts should be accompanied by a md5 and pgp signatures > . a 72-hour vote for the release artifact should be called on hadoop-dev. > . 3 binding +1 votes and a majority are required > . if the vote passes, the release can then posted to > www.apache.org/dist/lucene/hadoop for mirroring > This would bring us into accord with Apache's requirements, and better permit > large-cluster validation. > We should also build consensus for a release before we commence this process. > Perhaps we should aim for releases every two months instead of every month. > We should perhaps develop more elaborate branching and merging conventions > around releases. Currently we mostly lock-out changes intended for release > X+1 from trunk until release X is complete, which can be awkward. How can we > better manage that? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.