Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
MapReduce >> mail # dev >> Release numbering for branch-2 releases


+
Arun C Murthy 2013-01-29, 20:56
+
Stack 2013-01-31, 05:25
+
Arun C Murthy 2013-01-31, 20:12
+
Stack 2013-02-01, 20:35
+
Tom White 2013-02-01, 10:34
+
Andrew Purtell 2013-02-01, 18:52
+
Arun C Murthy 2013-02-04, 18:46
+
Stack 2013-02-04, 19:53
+
Owen OMalley 2013-02-04, 21:07
+
Suresh Srinivas 2013-02-04, 22:14
+
Todd Lipcon 2013-02-04, 22:36
+
Steve Loughran 2013-02-05, 04:50
+
Suresh Srinivas 2013-02-04, 19:20
+
Eli Collins 2013-01-31, 00:21
+
Arun C Murthy 2013-01-31, 01:10
+
Eli Collins 2013-01-31, 19:51
+
Arun C Murthy 2013-01-29, 22:40
Copy link to this message
-
Re: Release numbering for branch-2 releases
I still have a list of pending API/protocol cleanup in YARN that need to be
in before we even attempt supporting compatibility further down the road.
There's no way we can support wire compatibility with the APIs in the state
that they are in now. So, +1 for a beta sometime in March.

There are some early adopters, I am particularly speaking of YARN, who have
been instrumental in helping ironing out the alpha software, some with very
large clusters and end-user base. These users will continue to be affected
with these API/protocol changes, but the alpha tag was clearly meant to
clarify this. I think we should graciously send out a note (on general@)
about an impending beta from where everyone can except a high degree of
compatibility.

Just caught up with the discussion on the referred JIRAs. I can clearly see
how a single release with an umbrella alpha/beta tag is causing tensions
*only* because we have a single project and product. More reinforcement for
my proclivity towards separate releases and by extension towards the
projects' split.

Thanks,
+Vinod

On Tue, Jan 29, 2013 at 2:40 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:

> Thanks Suresh. Adding back other *-dev lists.
>
> On Jan 29, 2013, at 1:58 PM, Suresh Srinivas wrote:
>
> > +1 for a release with all the changes that are committed. That way it
> > carries all the important bug fixes.
> >
> >
> > So, rather than debate more, I had a brief chat with Suresh and Todd.
> Todd
> >> suggested calling the next release as hadoop-2.1.0-alpha to indicate the
> >> incompatibility a little better. This makes sense to me, as long as we
> are
> >> clear that we won't make any further *feature* releases in hadoop-2.0.x
> >> series (obviously we might be forced to do security/bug-fix release).
> >>
> >
> >
> > We have been incorrectly using point releases to introduce features.
> Given
> > there are many features in this release, calling it 2.1.0 instead of
> 2.0.3
> > makes sense. As you said, I am okay with the proposed plan as long as we
> do
> > not lapse back to introducing new features in point releases meant for
> > critical bugs.
>
>
>
--
+Vinod
Hortonworks Inc.
http://hortonworks.com/
+
Tom White 2013-02-01, 11:03
+
Stack 2013-02-03, 03:00
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB