Folks,

 There has been some discussions about incompatible changes in the 
hadoop-2.x.x-alpha releases on HADOOP-9070, HADOOP-9151, HADOOP-9192 and few 
other jiras. Frankly, I'm surprised about some of them since the 'alpha' 
moniker was precisely to harden apis by changing them if necessary, borne out 
by the fact that every  single release in hadoop-2 chain has had incompatible 
changes. This happened since we were releasing early, moving fast and breaking 
things. Furthermore, we'll have more in future as move towards stability of 
hadoop-2 similar to HDFS-4362, HDFS-4364 et al in HDFS and YARN-142 (api 
changes) for YARN.

 So, rather than debate more, I had a brief chat with Suresh and Todd. Todd 
suggested calling the next release as hadoop-2.1.0-alpha to indicate the 
incompatibility a little better. This makes sense to me, as long as we are 
clear that we won't make any further *feature* releases in hadoop-2.0.x series 
(obviously we might be forced to do security/bug-fix release).

 Going forward, I'd like to start locking down apis/protocols for a 'beta' 
release. This way we'll have one *final* opportunity post hadoop-2.1.0-alpha to 
make incompatible changes if necessary and we can call it hadoop-2.2.0-beta. 

 Post hadoop-2.2.0-beta we *should* lock down and not allow incompatible 
changes. This will allow us to go on to a hadoop-2.3.0 as a GA release. This 
forces us to do a real effort on making sure we lock down for hadoop-2.2.0-beta.

 In summary:
 # I plan to now release hadoop-2.1.0-alpha (this week).
 # We make a real effort to lock down apis/protocols and release 
hadoop-2.2.0-beta, say in March.
 # Post 'beta' release hadoop-2.3.0 as 'stable' sometime in May.

 I'll start a separate thread on 'locking protocols' w.r.t client-protocols v/s 
internal protocols (to facilitate rolling upgrades etc.), let's discuss this 
one separately.

 Makes sense? Thoughts?

thanks,
Arun
 
PS:  Between hadoop-2.2.0-beta and hadoop-2.3.0 we *might* be forced to make 
some incompatible changes due to *unforeseen circumstances*, but no more 
gratuitous changes are allowed.

Reply via email to