[
https://issues.apache.org/jira/browse/HADOOP-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484291
]
Arun C Murthy commented on HADOOP-1161:
---------------------------------------
In general I like the two-month cycle and clearly it's time for more elaborate
branching/merging... so a big +1.
W.r.t to improved releases IMO the biggest bang for the buck would come from
significantly better testing on large-clusters prior to releases. To that
effect I'd strongly vote for a code-freeze (atleast 2wks for a 1-month releases
and 3wks for 2-month releases). This would help 'soak-in' the features/fixes
and generally foster much better confidence in the releases.
Given the nature of the project i.e. large-scale etc. I'd not be very confident
of just 'ant test' since it's clearly very hard to achieve reasonable
code-coverage (clearly we could do better here too with more junit tests etc.)
and also to simulate the 'large-scale' part in test-suites on single-nodes.
Hence I'd be much more confident with a code-freeze and a reasonable amount of
regressions/benchmarks run on large-clusters.
Here is something along the lines of what I think would help:
1. Lets say we 0.15.0 target a release for Jan 1
2. We have a code-freeze (i.e. no new features henceforth) on Dec 15 (or Dec
10, earlier the better).
3. We release an early 0.15.0-rc1 (release candidate) on Dec15
4. We let Nigel and the test-suites/benchmarks loose on 0.15.0-rc1.
5. If we fix enough bugs and are reasonably confident we can release a
0.15.0-rc2 a week or so later (Dec 22).
6. Continue testing (i.e. test-suites and benchmarks) on 0.15.0-rc2 for
*atleast a week*.
7. Release more rcs (0.15.0-rc3, 0.15.0-rc4 etc.) if warranted (criticality of
bug etc.)
8. Finally promote the 'last-known' rc to 0.15.0
Rinse and repeat for 0.15.1 (only bug-fixes of course), while we continue
checking-in new features into 0.16.0 branch.
-*-*-
Thoughts?
> 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.
