hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosmin Lehene <cleh...@adobe.com>
Subject Re: [DISCUSSION] Release process
Date Wed, 31 Mar 2010 09:38:02 GMT

I'm glad we're heading towards a release. We'd like to better understand some aspects regarding
the release plan.

What would be the tentative release schedule, and what affects particular releases? We could
either continue with our current version or plan based on what's going to be released.

I guess an upgrade decision process is mostly influenced by the amount of work required to
update and test existing code for  API changes balanced by the features benefits from the
upgrade, with aspects such as Data Integrity being blockers.

Hence,  we'd like to understand how the following things map on, or affect, the next releases
(0.x, 1.x, 2.x)

* Data Integrity (I guess this should be blocking for any release)
* API compatibility (I understand this is the primary driver for the release major numbering)
* High level features(Append, Security, Avro, Rolling upgrades, etc. - this would map on a
time basis)
In our case we have code running on 0.21 and need "Append", with the current focus being Data
Integrity. We can handle an API change, but really concerned about Data Integrity. So, for
us, fixing any blocking issues on hdfs-0.21 (potentially 0.22) and then further maintaining
it stable would be the priority, regardless whether this will be 0.X, 1.X, or 2.X. Depending
on the result of this release schedule we might be able to stick with one of them or to fork
for a while.

Thanks for your help,

On Mar 31, 2010, at 6:22 AM, Owen O'Malley wrote:

> On Mar 30, 2010, at 3:40 PM, Doug Cutting wrote:
>> Another release we might consider is 1.0 based on 0.20.
> It is tempting and I think that 0.20 is *really* our 1.0, but I think  
> re-labeling a release a year after it came out would be confusing.
> I think that we should change the rules so that the remaining 0.X  
> releases are minor releases. That seems a relatively minor change and  
> just means that we can't remove deprecated items until 1.0.
> I'll volunteer to be release manager for a release branched in  
> November, which should be roughly 6 months after Tom's new 0.21 release.
> One possible release numbering would have the November release be 0.99  
> and a matching 1.0 that removes all of the deprecated methods.
> -- Owen

View raw message