Mailing-List: contact yarn-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-dev@hadoop.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [DISCUSS] Release numbering for stable 2.8 and beyond
From: Hitesh Shah <hitesh@apache.org>
In-Reply-To: <FAA30A53-C2BD-4380-9245-C8DBEC7BF386@hortonworks.com>
Date: Sun, 26 Apr 2015 09:51:11 -0700
Cc: "mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
 "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
 "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
 Vinod Kumar Vavilapalli <vinodkv@apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DC90604-C4F3-41EA-AD75-66EA5F29FCB3@apache.org>
References: 
 <CAMyYaRKomwk4L6ZupB1-V8d0EpYZzTDaHsQO4aWyXMPb8=y1Vg@mail.gmail.com>
 <CALwhT94yj67XSGEeM0FO_+zLJmfBZW=khq9eCVsximaWavCXwQ@mail.gmail.com>
 <CAGB5D2Z_DQrOo4uSXzw8UcocnC2fMG4BMVuBM1vBBPRPfYfD1Q@mail.gmail.com>
 <9F85F65E-D770-433F-BF9D-FAA501A7DBAD@hortonworks.com>
 <FAA30A53-C2BD-4380-9245-C8DBEC7BF386@hortonworks.com>
To: yarn-dev@hadoop.apache.org

There are a couple of different approaches we could take.=20

How about publishing/releasing bits such as =932.8.0-RC0=94. Downstream =
projects can depend on these and use them normally similar to the =
approach that they would have taken with release 2.8.0 or 2.8.0-alpha. =
After some baking ( or more RC suffixed releases), at some point, a =
proper 2.8.0 release could be made? The RC tag clearly indicates to =
downstream layers that things will be in flux slightly. Trying to =
distinguish incompatibilities between 2.8.0 and 2.8.1/2.8.2 ( just =
because 2.8.0 was tagged alpha in documentation ) are likely to be a =
nightmare to deal with especially for new features introduced in the 2.8 =
release ( which might get changed slightly based on usage feedback ).

Furthermore, considering the release history of hadoop, the likelihood =
that 2.9.0 will show up before 2.8.2 seems to be very high.

With respect to the proposed choice (1), I thought that HBase applied a =
different approach. The odd-number releases were always unstable and the =
even number releases were the stable ones. This =93could" make things a =
bit more clear for downstream users without needing to resort to =
modified versioned numbers ( with alpha/beta tags ) or requiring users =
to go look up the website to find out which particular version of 2.8.x =
was the first stable release.

thanks
=97 Hitesh


On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli =
<vinodkv@hortonworks.com> wrote:

> Forking the thread.
>=20
> In the previous 2.7.1 thread [1], there were enough yays to my =
proposal to wait for a bug-fix release or two before calling a 2.x =
release stable. There were some concerns about the naming.
>=20
> We have two options, taking 2.8 as an example
> (1) Release 2.8.0, call it as an alpha in documentation and release =
notes, wait for a 2.8.1/2.8.2 reasonably stable enough to be called as =
the first stable release of 2.8.
> (2) Release 2.8.0-alpha, 2.8.0-beta etc before culminating in a 2.8.0 =
stable release.
>=20
> (1) is what I preferred first up. This is what HBase used to do, and =
far beyond, in the linux kernel releases. It helps in scenarios where we =
are forced to downgrade a release, say due to major issues. We can =
simply announce it as not stable retroactively, change the pointers on =
our website and move on.
>=20
> Thoughts?
>=20
> Thanks,
> +Vinod
>=20
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>=20
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli =
<vinodkv@hortonworks.com> wrote:
>=20
>>=20
>> Sure, I agree it's better to have clear guidelines and scheme. Let me =
fork this thread about that.
>>=20
>> Re 2.7.0, I just forgot about the naming initially though I was clear =
in the discussion/voting. I so had to end up calling it alpha outside of =
the release artifact naming.
>>=20
>> Thanks
>> +Vinod
>>=20
>> On Apr 21, 2015, at 4:26 PM, Andrew Wang <andrew.wang@cloudera.com> =
wrote:
>>=20
>>> I would also like to support Karthik's proposal on the release =
thread about
>>> version numbering. 2.7.0 being "alpha" is pretty confusing since all =
of the
>>> other 2.x releases since GA have been stable. I think users would =
prefer a
>>> version like "2.8.0-alpha1" instead, which is very clear and similar =
to
>>> what we did for 2.0 and 2.1. Then we release 2.8.0 when we're =
actually
>>> stable.
>>>=20
>>> I don't know if it's retroactively possible to do this for 2.7.0, =
but it's
>>> something to consider for the next 2.7 alpha or beta or whatever.
>>>=20
>=20