You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Nigel Daley (JIRA)" <ji...@apache.org> on 2007/04/18 21:54:15 UTC
[jira] Commented: (HADOOP-1161) need improved release process
[ https://issues.apache.org/jira/browse/HADOOP-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489864 ]
Nigel Daley commented on HADOOP-1161:
-------------------------------------
To summarize, I think we've roughly agreed to the following dev and release process (bullet numbers are for reference purposes is remaining discussion):
Development:
1) use trunk for main development
2) patches must not mix bug fixes and enhancements
Major Releases:
3) major releases every two months on the first Friday, provided release X-1 has reached stability
4) 2 weeks before the targeted release date:
a) create a release branch
b) feature freeze the branch
c) bug fixes are applied to trunk first, then backported into the release branch
5) when the release branch seems stable, a release candidate is created
a) release candidate builds should be placed in lucene.apache.org/hadoop/dev/dist
b) release candidates should be accompanied by a md5 and pgp signatures
6) 72-hours before the targeted release date, a vote on the release candidate is explicitly called for on hadoop-dev
a) 3 binding +1 votes and a majority are required
b) if the vote passes, the release can then posted to www.apache.org/dist/lucene/hadoop for mirroring
A couple questions:
- Do you agree with my summary?
- In 5, how do we agree on 'stable'? call a vote?
- In 3, what happens if release X-1 isn't stable? leave it unspecified?
- In 6b, what if the vote doesn't pass? leave it unspecified?
> 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.