hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun C Murthy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1161) need improved release process
Date Tue, 27 Mar 2007 17:48:32 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484517
] 

Arun C Murthy commented on HADOOP-1161:
---------------------------------------

Actually I'd like to propose a small variation of Tom's thoughts:

Step2 would mean we create a 0.16.0 branch and all 'new' features go into that branch. Bug
fixes go into the trunk which will eventually be the 0.15.0 release. We await a little more
time to check if we need to create a 0.15.1 branch for it's critical-fixes (say a week?).
And only when we are done with 0.15.1, 0.15.2 etc. (if need be) do we then merge 0.16.0 into
trunk and the process repeats.

The reason I propose a 0.16.0 branch in Step2 v/s 0.15.0 branch is that it becomes easier
to create a 0.15.1 branch after we cut the 0.15.0 release (i.e. we can avoid the hassle of
branching from 0.15.0 branch and just branch from trunk).

I do not like the idea of applying the same patch more than one place (i.e trunk and a branch
etc.) - merging handles this nicely, provided we maintain a bit of discipline. 


> 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.


Mime
View raw message