[DISCUSS] Release numbering for stable 2.8 and beyond

[Vinod Kumar Vavilapalli <vi...@hortonworks.com>]

Forking the thread.

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.

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.

(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.

Thoughts?

Thanks,
+Vinod

[1] http://markmail.org/thread/ogzk4phj6wsdpssu

On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <vi...@hortonworks.com> wrote:

> 
> Sure, I agree it's better to have clear guidelines and scheme. Let me fork this thread about that.
> 
> 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.
> 
> Thanks
> +Vinod
> 
> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com> wrote:
> 
>> 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.
>> 
>> 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.
>> 

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Karthik Kambatla <ka...@cloudera.com>]

Approach (1) seems like a good way to handle stability concerns people
might have. If we explicitly distinguish between current and stable (i.e.,
not set them both to the latest release). It would be nice to do a VOTE for
calling a release stable.

I would use approach (2) for compatibility concerns. Ideally, I wouldn't
ship anything in a release unless we are sure we can preserve its
compatibility. If we really think a feature is not ready, we could always
guard them with private configs that devs or beta-testers could enable to
use. In the past, there have been proposals about labeling specific
features alpha and beta. I am open to considering it provided we define
what those terms mean, ideally in our compat guidelines.

On Wed, Apr 22, 2015 at 2:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> Thanks for forking this Vinod,
>
> Linux used to do the odd/even minor versions for unstable/stable, but that
> went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
> always stable. The odd/even though was at least a convention everyone knew
> about.
>
> Stack can comment better than I about HBase versioning, but my impression
> is that they do something similar. Evens are stable, odds are not.
>
> I'd be okay with an even/odd convention, but it would still be our third
> versioning convention in as many years.
>
> I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
> since 2.2 has been that everything is compatible / stable. Adding a tag
> makes it very clear that we are now doing unstable releases. This also has
> the pleasing property that we culminate in a 2.x.0, rather than stable
> starting at 2.x.4 or whatever. Much simpler than having to consult a
> website.
>
> Re (2), we should add a number (e.g. alpha2) too in case there's more than
> one alpha or beta too.
>
> Best,
> Andrew
>
> On Wed, Apr 22, 2015 at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > >
> > > Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >
> > > 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.
> > >
> > > Thanks
> > > +Vinod
> > >
> > > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >
> > >> 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.
> > >>
> > >> 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.
> > >>
> >
> >
>



-- 
Karthik Kambatla
Software Engineer, Cloudera Inc.
--------------------------------------------
http://five.sentenc.es

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Karthik Kambatla <ka...@cloudera.com>]

Approach (1) seems like a good way to handle stability concerns people
might have. If we explicitly distinguish between current and stable (i.e.,
not set them both to the latest release). It would be nice to do a VOTE for
calling a release stable.

I would use approach (2) for compatibility concerns. Ideally, I wouldn't
ship anything in a release unless we are sure we can preserve its
compatibility. If we really think a feature is not ready, we could always
guard them with private configs that devs or beta-testers could enable to
use. In the past, there have been proposals about labeling specific
features alpha and beta. I am open to considering it provided we define
what those terms mean, ideally in our compat guidelines.

On Wed, Apr 22, 2015 at 2:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> Thanks for forking this Vinod,
>
> Linux used to do the odd/even minor versions for unstable/stable, but that
> went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
> always stable. The odd/even though was at least a convention everyone knew
> about.
>
> Stack can comment better than I about HBase versioning, but my impression
> is that they do something similar. Evens are stable, odds are not.
>
> I'd be okay with an even/odd convention, but it would still be our third
> versioning convention in as many years.
>
> I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
> since 2.2 has been that everything is compatible / stable. Adding a tag
> makes it very clear that we are now doing unstable releases. This also has
> the pleasing property that we culminate in a 2.x.0, rather than stable
> starting at 2.x.4 or whatever. Much simpler than having to consult a
> website.
>
> Re (2), we should add a number (e.g. alpha2) too in case there's more than
> one alpha or beta too.
>
> Best,
> Andrew
>
> On Wed, Apr 22, 2015 at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > >
> > > Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >
> > > 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.
> > >
> > > Thanks
> > > +Vinod
> > >
> > > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >
> > >> 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.
> > >>
> > >> 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.
> > >>
> >
> >
>



-- 
Karthik Kambatla
Software Engineer, Cloudera Inc.
--------------------------------------------
http://five.sentenc.es

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Karthik Kambatla <ka...@cloudera.com>]

Approach (1) seems like a good way to handle stability concerns people
might have. If we explicitly distinguish between current and stable (i.e.,
not set them both to the latest release). It would be nice to do a VOTE for
calling a release stable.

I would use approach (2) for compatibility concerns. Ideally, I wouldn't
ship anything in a release unless we are sure we can preserve its
compatibility. If we really think a feature is not ready, we could always
guard them with private configs that devs or beta-testers could enable to
use. In the past, there have been proposals about labeling specific
features alpha and beta. I am open to considering it provided we define
what those terms mean, ideally in our compat guidelines.

On Wed, Apr 22, 2015 at 2:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> Thanks for forking this Vinod,
>
> Linux used to do the odd/even minor versions for unstable/stable, but that
> went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
> always stable. The odd/even though was at least a convention everyone knew
> about.
>
> Stack can comment better than I about HBase versioning, but my impression
> is that they do something similar. Evens are stable, odds are not.
>
> I'd be okay with an even/odd convention, but it would still be our third
> versioning convention in as many years.
>
> I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
> since 2.2 has been that everything is compatible / stable. Adding a tag
> makes it very clear that we are now doing unstable releases. This also has
> the pleasing property that we culminate in a 2.x.0, rather than stable
> starting at 2.x.4 or whatever. Much simpler than having to consult a
> website.
>
> Re (2), we should add a number (e.g. alpha2) too in case there's more than
> one alpha or beta too.
>
> Best,
> Andrew
>
> On Wed, Apr 22, 2015 at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > >
> > > Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >
> > > 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.
> > >
> > > Thanks
> > > +Vinod
> > >
> > > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >
> > >> 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.
> > >>
> > >> 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.
> > >>
> >
> >
>



-- 
Karthik Kambatla
Software Engineer, Cloudera Inc.
--------------------------------------------
http://five.sentenc.es

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Karthik Kambatla <ka...@cloudera.com>]

Approach (1) seems like a good way to handle stability concerns people
might have. If we explicitly distinguish between current and stable (i.e.,
not set them both to the latest release). It would be nice to do a VOTE for
calling a release stable.

I would use approach (2) for compatibility concerns. Ideally, I wouldn't
ship anything in a release unless we are sure we can preserve its
compatibility. If we really think a feature is not ready, we could always
guard them with private configs that devs or beta-testers could enable to
use. In the past, there have been proposals about labeling specific
features alpha and beta. I am open to considering it provided we define
what those terms mean, ideally in our compat guidelines.

On Wed, Apr 22, 2015 at 2:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> Thanks for forking this Vinod,
>
> Linux used to do the odd/even minor versions for unstable/stable, but that
> went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
> always stable. The odd/even though was at least a convention everyone knew
> about.
>
> Stack can comment better than I about HBase versioning, but my impression
> is that they do something similar. Evens are stable, odds are not.
>
> I'd be okay with an even/odd convention, but it would still be our third
> versioning convention in as many years.
>
> I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
> since 2.2 has been that everything is compatible / stable. Adding a tag
> makes it very clear that we are now doing unstable releases. This also has
> the pleasing property that we culminate in a 2.x.0, rather than stable
> starting at 2.x.4 or whatever. Much simpler than having to consult a
> website.
>
> Re (2), we should add a number (e.g. alpha2) too in case there's more than
> one alpha or beta too.
>
> Best,
> Andrew
>
> On Wed, Apr 22, 2015 at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > >
> > > Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >
> > > 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.
> > >
> > > Thanks
> > > +Vinod
> > >
> > > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >
> > >> 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.
> > >>
> > >> 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.
> > >>
> >
> >
>



-- 
Karthik Kambatla
Software Engineer, Cloudera Inc.
--------------------------------------------
http://five.sentenc.es

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

Thanks for forking this Vinod,

Linux used to do the odd/even minor versions for unstable/stable, but that
went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
always stable. The odd/even though was at least a convention everyone knew
about.

Stack can comment better than I about HBase versioning, but my impression
is that they do something similar. Evens are stable, odds are not.

I'd be okay with an even/odd convention, but it would still be our third
versioning convention in as many years.

I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
since 2.2 has been that everything is compatible / stable. Adding a tag
makes it very clear that we are now doing unstable releases. This also has
the pleasing property that we culminate in a 2.x.0, rather than stable
starting at 2.x.4 or whatever. Much simpler than having to consult a
website.

Re (2), we should add a number (e.g. alpha2) too in case there's more than
one alpha or beta too.

Best,
Andrew

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Sandy Ryza <sa...@cloudera.com>]

My understanding was that the main reason that we labeled 2.0 alpha and 2.1
beta is that we wanted flexibility to make breaking API changes.

Is that the case now with 2.7?  I.e. do we have APIs labeled as Public /
Stable that we want freedom to change in 2.8?  If not, I definitely don't
think the release merits a special tag.  We should just make sure its bugs
are well documented.

-Sandy

On Mon, Apr 27, 2015 at 10:45 AM, Andrew Wang <an...@cloudera.com>
wrote:

> I think Karthik correctly identified the two reasons we might want to
> denote a release as "unstable":
>
> a) Compatibility. Whether we have freedom to break compatibility before the
> final release, i.e. what "alpha" typically means.
>
> b) Quality. As Konst says, a release can be allowed to break compatibility
> ("alpha") but itself still be a high quality release.
>
> We could try and separate out these two concerns when it comes to
> versioning, but I think in reality users only care about prod vs. non-prod,
> which is why many other projects (Linux, HBase, etc) just have two release
> lines: "stable" (compatible/good-quality) vs. "unstable"
> (unknown-compatible/unknown-quality).
>
> To this end, I don't mind what we choose, as long as the difference between
> stable and unstable is denoted by the version number. I don't like the idea
> of tagging a release as good after the fact (1). The other projects we've
> used as examples make strong statements about their stable release lines,
> and we should too. Our downstreams and end users will appreciate clarity
> from the version number.
>
> Best,
> Andrew
>
> On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:
>
> > There are a couple of different approaches we could take.
> >
> > How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> > — Hitesh
> >
> >
> >
> >
> >
> > On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > > Forking the thread.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > (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.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > +Vinod
> > >
> > > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> > >
> > > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> > >
> > >>
> > >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >>
> > >> 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.
> > >>
> > >> Thanks
> > >> +Vinod
> > >>
> > >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >>
> > >>> 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.
> > >>>
> > >>> 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.
> > >>>
> > >
> >
> >
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Konstantin Boudnik <co...@apache.org>]

On Mon, Apr 27, 2015 at 10:45AM, Andrew Wang wrote:
> I think Karthik correctly identified the two reasons we might want to
> denote a release as "unstable":
> 
> a) Compatibility. Whether we have freedom to break compatibility before the
> final release, i.e. what "alpha" typically means.

Breaking compatibility within minor releases is a very novel idea, introduced
to the world by Scala, if I am not mistaken. In general though, it is a pretty
bad practice to have 2.8.0 be incompatible with 2.8.1 - this isn't what
normally is expected from a subminor update.

> b) Quality. As Konst says, a release can be allowed to break compatibility
> ("alpha") but itself still be a high quality release.

I don't think Konst has advocated to make subminors incopatible ;)

As for the original question, I'd really go with a normal versioning and
just documenting any stability concerns.

Cos

> We could try and separate out these two concerns when it comes to
> versioning, but I think in reality users only care about prod vs. non-prod,
> which is why many other projects (Linux, HBase, etc) just have two release
> lines: "stable" (compatible/good-quality) vs. "unstable"
> (unknown-compatible/unknown-quality).
> 
> To this end, I don't mind what we choose, as long as the difference between
> stable and unstable is denoted by the version number. I don't like the idea
> of tagging a release as good after the fact (1). The other projects we've
> used as examples make strong statements about their stable release lines,
> and we should too. Our downstreams and end users will appreciate clarity
> from the version number.
> 
> Best,
> Andrew
> 
> On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:
> 
> > There are a couple of different approaches we could take.
> >
> > How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> > — Hitesh
> >
> >
> >
> >
> >
> > On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > > Forking the thread.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > (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.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > +Vinod
> > >
> > > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> > >
> > > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> > >
> > >>
> > >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >>
> > >> 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.
> > >>
> > >> Thanks
> > >> +Vinod
> > >>
> > >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >>
> > >>> 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.
> > >>>
> > >>> 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.
> > >>>
> > >
> >
> >

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Sandy Ryza <sa...@cloudera.com>]

My understanding was that the main reason that we labeled 2.0 alpha and 2.1
beta is that we wanted flexibility to make breaking API changes.

Is that the case now with 2.7?  I.e. do we have APIs labeled as Public /
Stable that we want freedom to change in 2.8?  If not, I definitely don't
think the release merits a special tag.  We should just make sure its bugs
are well documented.

-Sandy

On Mon, Apr 27, 2015 at 10:45 AM, Andrew Wang <an...@cloudera.com>
wrote:

> I think Karthik correctly identified the two reasons we might want to
> denote a release as "unstable":
>
> a) Compatibility. Whether we have freedom to break compatibility before the
> final release, i.e. what "alpha" typically means.
>
> b) Quality. As Konst says, a release can be allowed to break compatibility
> ("alpha") but itself still be a high quality release.
>
> We could try and separate out these two concerns when it comes to
> versioning, but I think in reality users only care about prod vs. non-prod,
> which is why many other projects (Linux, HBase, etc) just have two release
> lines: "stable" (compatible/good-quality) vs. "unstable"
> (unknown-compatible/unknown-quality).
>
> To this end, I don't mind what we choose, as long as the difference between
> stable and unstable is denoted by the version number. I don't like the idea
> of tagging a release as good after the fact (1). The other projects we've
> used as examples make strong statements about their stable release lines,
> and we should too. Our downstreams and end users will appreciate clarity
> from the version number.
>
> Best,
> Andrew
>
> On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:
>
> > There are a couple of different approaches we could take.
> >
> > How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> > — Hitesh
> >
> >
> >
> >
> >
> > On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > > Forking the thread.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > (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.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > +Vinod
> > >
> > > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> > >
> > > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> > >
> > >>
> > >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >>
> > >> 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.
> > >>
> > >> Thanks
> > >> +Vinod
> > >>
> > >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >>
> > >>> 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.
> > >>>
> > >>> 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.
> > >>>
> > >
> >
> >
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Sandy Ryza <sa...@cloudera.com>]

My understanding was that the main reason that we labeled 2.0 alpha and 2.1
beta is that we wanted flexibility to make breaking API changes.

Is that the case now with 2.7?  I.e. do we have APIs labeled as Public /
Stable that we want freedom to change in 2.8?  If not, I definitely don't
think the release merits a special tag.  We should just make sure its bugs
are well documented.

-Sandy

On Mon, Apr 27, 2015 at 10:45 AM, Andrew Wang <an...@cloudera.com>
wrote:

> I think Karthik correctly identified the two reasons we might want to
> denote a release as "unstable":
>
> a) Compatibility. Whether we have freedom to break compatibility before the
> final release, i.e. what "alpha" typically means.
>
> b) Quality. As Konst says, a release can be allowed to break compatibility
> ("alpha") but itself still be a high quality release.
>
> We could try and separate out these two concerns when it comes to
> versioning, but I think in reality users only care about prod vs. non-prod,
> which is why many other projects (Linux, HBase, etc) just have two release
> lines: "stable" (compatible/good-quality) vs. "unstable"
> (unknown-compatible/unknown-quality).
>
> To this end, I don't mind what we choose, as long as the difference between
> stable and unstable is denoted by the version number. I don't like the idea
> of tagging a release as good after the fact (1). The other projects we've
> used as examples make strong statements about their stable release lines,
> and we should too. Our downstreams and end users will appreciate clarity
> from the version number.
>
> Best,
> Andrew
>
> On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:
>
> > There are a couple of different approaches we could take.
> >
> > How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> > — Hitesh
> >
> >
> >
> >
> >
> > On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> >
> > > Forking the thread.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > (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.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > +Vinod
> > >
> > > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> > >
> > > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> > vinodkv@hortonworks.com> wrote:
> > >
> > >>
> > >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> > fork this thread about that.
> > >>
> > >> 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.
> > >>
> > >> Thanks
> > >> +Vinod
> > >>
> > >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> > wrote:
> > >>
> > >>> 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.
> > >>>
> > >>> 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.
> > >>>
> > >
> >
> >
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

I think Karthik correctly identified the two reasons we might want to
denote a release as "unstable":

a) Compatibility. Whether we have freedom to break compatibility before the
final release, i.e. what "alpha" typically means.

b) Quality. As Konst says, a release can be allowed to break compatibility
("alpha") but itself still be a high quality release.

We could try and separate out these two concerns when it comes to
versioning, but I think in reality users only care about prod vs. non-prod,
which is why many other projects (Linux, HBase, etc) just have two release
lines: "stable" (compatible/good-quality) vs. "unstable"
(unknown-compatible/unknown-quality).

To this end, I don't mind what we choose, as long as the difference between
stable and unstable is denoted by the version number. I don't like the idea
of tagging a release as good after the fact (1). The other projects we've
used as examples make strong statements about their stable release lines,
and we should too. Our downstreams and end users will appreciate clarity
from the version number.

Best,
Andrew

On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:

> There are a couple of different approaches we could take.
>
> How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> — Hitesh
>
>
>
>
>
> On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
> >
> >>
> >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >>
> >> 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.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

I think Karthik correctly identified the two reasons we might want to
denote a release as "unstable":

a) Compatibility. Whether we have freedom to break compatibility before the
final release, i.e. what "alpha" typically means.

b) Quality. As Konst says, a release can be allowed to break compatibility
("alpha") but itself still be a high quality release.

We could try and separate out these two concerns when it comes to
versioning, but I think in reality users only care about prod vs. non-prod,
which is why many other projects (Linux, HBase, etc) just have two release
lines: "stable" (compatible/good-quality) vs. "unstable"
(unknown-compatible/unknown-quality).

To this end, I don't mind what we choose, as long as the difference between
stable and unstable is denoted by the version number. I don't like the idea
of tagging a release as good after the fact (1). The other projects we've
used as examples make strong statements about their stable release lines,
and we should too. Our downstreams and end users will appreciate clarity
from the version number.

Best,
Andrew

On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:

> There are a couple of different approaches we could take.
>
> How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> — Hitesh
>
>
>
>
>
> On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
> >
> >>
> >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >>
> >> 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.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

I think Karthik correctly identified the two reasons we might want to
denote a release as "unstable":

a) Compatibility. Whether we have freedom to break compatibility before the
final release, i.e. what "alpha" typically means.

b) Quality. As Konst says, a release can be allowed to break compatibility
("alpha") but itself still be a high quality release.

We could try and separate out these two concerns when it comes to
versioning, but I think in reality users only care about prod vs. non-prod,
which is why many other projects (Linux, HBase, etc) just have two release
lines: "stable" (compatible/good-quality) vs. "unstable"
(unknown-compatible/unknown-quality).

To this end, I don't mind what we choose, as long as the difference between
stable and unstable is denoted by the version number. I don't like the idea
of tagging a release as good after the fact (1). The other projects we've
used as examples make strong statements about their stable release lines,
and we should too. Our downstreams and end users will appreciate clarity
from the version number.

Best,
Andrew

On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:

> There are a couple of different approaches we could take.
>
> How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> — Hitesh
>
>
>
>
>
> On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
> >
> >>
> >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >>
> >> 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.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

I think Karthik correctly identified the two reasons we might want to
denote a release as "unstable":

a) Compatibility. Whether we have freedom to break compatibility before the
final release, i.e. what "alpha" typically means.

b) Quality. As Konst says, a release can be allowed to break compatibility
("alpha") but itself still be a high quality release.

We could try and separate out these two concerns when it comes to
versioning, but I think in reality users only care about prod vs. non-prod,
which is why many other projects (Linux, HBase, etc) just have two release
lines: "stable" (compatible/good-quality) vs. "unstable"
(unknown-compatible/unknown-quality).

To this end, I don't mind what we choose, as long as the difference between
stable and unstable is denoted by the version number. I don't like the idea
of tagging a release as good after the fact (1). The other projects we've
used as examples make strong statements about their stable release lines,
and we should too. Our downstreams and end users will appreciate clarity
from the version number.

Best,
Andrew

On Sun, Apr 26, 2015 at 9:51 AM, Hitesh Shah <hi...@apache.org> wrote:

> There are a couple of different approaches we could take.
>
> How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
> — Hitesh
>
>
>
>
>
> On Apr 22, 2015, at 2:17 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > Forking the thread.
> >
> > 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.
> >
> > 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.
> >
> > (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.
> >
> > Thoughts?
> >
> > Thanks,
> > +Vinod
> >
> > [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> >
> > On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
> >
> >>
> >> Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >>
> >> 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.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Hitesh Shah <hi...@apache.org>]

There are a couple of different approaches we could take. 

How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
— Hitesh





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

> Forking the thread.
> 
> 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.
> 
> 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.
> 
> (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.
> 
> Thoughts?
> 
> Thanks,
> +Vinod
> 
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> 
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <vi...@hortonworks.com> wrote:
> 
>> 
>> Sure, I agree it's better to have clear guidelines and scheme. Let me fork this thread about that.
>> 
>> 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.
>> 
>> Thanks
>> +Vinod
>> 
>> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com> wrote:
>> 
>>> 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.
>>> 
>>> 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.
>>> 
> 

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

Thanks for forking this Vinod,

Linux used to do the odd/even minor versions for unstable/stable, but that
went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
always stable. The odd/even though was at least a convention everyone knew
about.

Stack can comment better than I about HBase versioning, but my impression
is that they do something similar. Evens are stable, odds are not.

I'd be okay with an even/odd convention, but it would still be our third
versioning convention in as many years.

I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
since 2.2 has been that everything is compatible / stable. Adding a tag
makes it very clear that we are now doing unstable releases. This also has
the pleasing property that we culminate in a 2.x.0, rather than stable
starting at 2.x.4 or whatever. Much simpler than having to consult a
website.

Re (2), we should add a number (e.g. alpha2) too in case there's more than
one alpha or beta too.

Best,
Andrew

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

Thanks for forking this Vinod,

Linux used to do the odd/even minor versions for unstable/stable, but that
went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
always stable. The odd/even though was at least a convention everyone knew
about.

Stack can comment better than I about HBase versioning, but my impression
is that they do something similar. Evens are stable, odds are not.

I'd be okay with an even/odd convention, but it would still be our third
versioning convention in as many years.

I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
since 2.2 has been that everything is compatible / stable. Adding a tag
makes it very clear that we are now doing unstable releases. This also has
the pleasing property that we culminate in a 2.x.0, rather than stable
starting at 2.x.4 or whatever. Much simpler than having to consult a
website.

Re (2), we should add a number (e.g. alpha2) too in case there's more than
one alpha or beta too.

Best,
Andrew

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Hitesh Shah <hi...@apache.org>]

There are a couple of different approaches we could take. 

How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
— Hitesh





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

> Forking the thread.
> 
> 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.
> 
> 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.
> 
> (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.
> 
> Thoughts?
> 
> Thanks,
> +Vinod
> 
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> 
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <vi...@hortonworks.com> wrote:
> 
>> 
>> Sure, I agree it's better to have clear guidelines and scheme. Let me fork this thread about that.
>> 
>> 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.
>> 
>> Thanks
>> +Vinod
>> 
>> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com> wrote:
>> 
>>> 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.
>>> 
>>> 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.
>>> 
> 

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Hitesh Shah <hi...@apache.org>]

There are a couple of different approaches we could take. 

How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
— Hitesh





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

> Forking the thread.
> 
> 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.
> 
> 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.
> 
> (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.
> 
> Thoughts?
> 
> Thanks,
> +Vinod
> 
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> 
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <vi...@hortonworks.com> wrote:
> 
>> 
>> Sure, I agree it's better to have clear guidelines and scheme. Let me fork this thread about that.
>> 
>> 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.
>> 
>> Thanks
>> +Vinod
>> 
>> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com> wrote:
>> 
>>> 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.
>>> 
>>> 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.
>>> 
> 

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Hitesh Shah <hi...@apache.org>]

There are a couple of different approaches we could take. 

How about publishing/releasing bits such as “2.8.0-RC0”. 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 “could" 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
— Hitesh





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

> Forking the thread.
> 
> 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.
> 
> 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.
> 
> (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.
> 
> Thoughts?
> 
> Thanks,
> +Vinod
> 
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
> 
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <vi...@hortonworks.com> wrote:
> 
>> 
>> Sure, I agree it's better to have clear guidelines and scheme. Let me fork this thread about that.
>> 
>> 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.
>> 
>> Thanks
>> +Vinod
>> 
>> On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com> wrote:
>> 
>>> 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.
>>> 
>>> 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.
>>> 
> 

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Konstantin Shvachko <sh...@gmail.com>]

I don't think it makes sense to imprint the release quality with its
version.
They should be separate. And our recommendation for the quality can be
reflected in the documentation.
(1) is the way to go.

We had "alpha" imprinted in 2.0.5-alpha version, but both 2.0.5 and 2.0.6
releases were quite stable, for me and many others.

Thanks,
--Konst

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Konstantin Shvachko <sh...@gmail.com>]

I don't think it makes sense to imprint the release quality with its
version.
They should be separate. And our recommendation for the quality can be
reflected in the documentation.
(1) is the way to go.

We had "alpha" imprinted in 2.0.5-alpha version, but both 2.0.5 and 2.0.6
releases were quite stable, for me and many others.

Thanks,
--Konst

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Konstantin Shvachko <sh...@gmail.com>]

I don't think it makes sense to imprint the release quality with its
version.
They should be separate. And our recommendation for the quality can be
reflected in the documentation.
(1) is the way to go.

We had "alpha" imprinted in 2.0.5-alpha version, but both 2.0.5 and 2.0.6
releases were quite stable, for me and many others.

Thanks,
--Konst

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Konstantin Shvachko <sh...@gmail.com>]

I don't think it makes sense to imprint the release quality with its
version.
They should be separate. And our recommendation for the quality can be
reflected in the documentation.
(1) is the way to go.

We had "alpha" imprinted in 2.0.5-alpha version, but both 2.0.5 and 2.0.6
releases were quite stable, for me and many others.

Thanks,
--Konst

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>

Re: [DISCUSS] Release numbering for stable 2.8 and beyond

[Andrew Wang <an...@cloudera.com>]

Thanks for forking this Vinod,

Linux used to do the odd/even minor versions for unstable/stable, but that
went away when 2.6 lasted forever. With the 3.x and 4.x I think it's just
always stable. The odd/even though was at least a convention everyone knew
about.

Stack can comment better than I about HBase versioning, but my impression
is that they do something similar. Evens are stable, odds are not.

I'd be okay with an even/odd convention, but it would still be our third
versioning convention in as many years.

I like (2) since it's similar to what we did with 2.0 and 2.1. Our contract
since 2.2 has been that everything is compatible / stable. Adding a tag
makes it very clear that we are now doing unstable releases. This also has
the pleasing property that we culminate in a 2.x.0, rather than stable
starting at 2.x.4 or whatever. Much simpler than having to consult a
website.

Re (2), we should add a number (e.g. alpha2) too in case there's more than
one alpha or beta too.

Best,
Andrew

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

> Forking the thread.
>
> 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.
>
> 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.
>
> (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.
>
> Thoughts?
>
> Thanks,
> +Vinod
>
> [1] http://markmail.org/thread/ogzk4phj6wsdpssu
>
> On Apr 21, 2015, at 4:59 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> >
> > Sure, I agree it's better to have clear guidelines and scheme. Let me
> fork this thread about that.
> >
> > 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.
> >
> > Thanks
> > +Vinod
> >
> > On Apr 21, 2015, at 4:26 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
>
>