hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: [DISCUSSION] Release process
Date Thu, 01 Apr 2010 21:38:09 GMT
Chris Douglas wrote:
>>  - de-deprecate "classic" mapred APIs (no Jira issue yet)
> Why?

So that folks can be told that if their code compiles without 
deprecation warnings against 1.0 then it should work for all 1.x releases.

> I don't mind releasing 1.0 with the classic APIs. Given the installed
> base, it's probably required. But let's not kill the new APIs by
> calling them "experimental," thereby granting the old ones "official"
> status at the moment the new ones become viable.

I was thinking that the new APIs should be 'public evolving' in 1.0. 
The classic APIs would be 'public stable'.  Unless we don't want to 
reserve the right to still evolve the new APIs between now and 2.0.

> OK. From some previous messages, I thought you were proposing some mix
> of 0.20 + security + HDFS-200 + et al., to better reflect what many
> run in production, possibly spreading that backporting work over
> several 1.x releases.

I did suggest that it would be good to subsequently release a version of 
Y!'s 0.20-based security patches as a 1.1 release.  That's where Y! will 
first qualify security, and it seems a shame not to release that 
version.  But perhaps this will prove impractical for some reason.

> This comparably meager set- with a vote on
> HDFS-200- could easily be 0.20.3, plus a set of bug fixes Todd and I
> have been assembling.

It could indeed instead be named 0.20.3, but if we agree that this 
(clarified with Tom's annotations) establishes the 1.0 API, then it 
would be good to number it as such, no?

>> Would you strongly oppose such a 3-week process?
> Having spent 2009 in the shadow of 0.20, I oppose any decision that
> prevents Apache from releasing the last year of work, or backporting
> existing work *again* onto that branch.

I don't see that this would prevent or discourage any other release. 
Nor does it require you to backport anything.  Any backporting would be 
voluntary.  Tom's privately told me he doesn't expect it to be difficult 
to backport HADOOP-6668 & MAPREDUCE-1623 (stability annotations) or 
MAPREDUCE-1650 (exclude private from javadoc), and I'm willing to 
backport those if he doesn't.

> With 0.21 finally coming out,
> a line of 1.x releases based on 0.20 would kneecap Owen and Tom's
> effort to restart the project.

How so?

It seems you do oppose this proposal.  Would you veto code changes 
required to make such a release with a technical rationale?  Would you 
vote -1 in the (majority-based) release vote?


View raw message