Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - Release plans


Copy link to this message
-
Re: Release plans
Stack 2010-02-20, 22:04
On Fri, Feb 19, 2010 at 4:23 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> Can we make a decision on basing 21 on the current branch and if it's
> decided that 22 can't remove stuff that was in 20 we'll go back and do
> the necessary additions on 21 and trunk? Suspect that decision will
> take a lot more back and forth, but needs to conclude before 21 is
> released.
>

Lets.

Regards 0.21/current-branch release, as has been suggested above,
first we need to figure the release master.  No release master, no
release.  If we have a release master, then I suggest we vote on
current branch being released as 0.21 as soon as the blockers are
cleared.

I don't think we need muddy the above vote with whether or not 0.21
maintains API combatibility with 0.20.  IMO, it must (because Y! want
to have the 0.20 API in place when January 2011 rolls around).  This
makes 0.21 a "minor" release -- something we've not done before (For
the record, I also had a misunderstanding that what we were doing up
to this was major and patch only).  So, part of the release process
would involve ensuring no removed deprecations, etc.

As DC has been saying, this requirement that releases between now and
January 2011 not change APIs makes 0.20 retroactively into a "major"
release.  0.20 is the release where major shifted left in our
versioning scheme and minor releases came into play.  0.21 and 0.22
will be minor releases. Can we just acknowledge this fact, that there
was a step at version 0.20, update the wiki around versioning -- its
currently wrong anyways as Elis' points out -- and just move on?
Going back and calling 0.20 a 1.0 seems more apt to create confusion
and besides, I'm with Allen that hadoop 1.0 needs wire compatibility
before the 1.0 can roll around.

Thanks,
St.Ack
P.S. +1 on branching as soon as avro and security are in, etc.