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

Switch to Threaded View
MapReduce, mail # dev - Release numbering for branch-2 releases


Copy link to this message
-
Re: Release numbering for branch-2 releases
Tom White 2013-02-01, 11:03
On Wed, Jan 30, 2013 at 11:32 PM, Vinod Kumar Vavilapalli
<[EMAIL PROTECTED]> wrote:
> 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.

To let others track these it would be useful if they were tagged in
JIRA with a label (e.g. apichange).

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

Good point. There's nothing to stop us doing separate releases of
sub-project components now. Doing so might help us find
incompatibilities between the different components in a release line
(2.x at the moment).

>
> 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/