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 Threaded View
Hadoop >> mail # dev >> Re: Heads up - 2.0.5-beta


Copy link to this message
-
Re: Heads up - 2.0.5-beta
If there are no objections, I'll start a vote on this proposal now.

Thanks,
--Konstantin
On Tue, Apr 30, 2013 at 4:28 PM, Konstantin Shvachko
<[EMAIL PROTECTED]>wrote:

> Hi Arun,
>
> I am agnostic about version numbers too, as long as the count goes up.
> The discussion you are referring to is somewhat outdated, it was talking
> about 2.0.4-beta, which we already passed. It is talking about producing a
> series "not suitable for general consumption", which isn't correct for the
> latest release 2.0.4. That discussion clearly outlined general (or
> specific) frustration about breaking compatibility from top level projects.
>
> You are not listing new features for MR and YARN.
> So it will only be about the four HDFS features Suresh proposed for 2.0.5.
> As I said earlier my problem with them is that each is big enough to
> destabilize the code base, and big enough to be targeted for a separate
> release. The latter relates to the "streamlining" thread on general@.
> I also think the proposed features will delay stable 2.x beyond the
> time-frame you projected, because some of them are not implemented yet, and
> Windows is in unknown to me condition, as integration builds are still not
> run for it.
>
> If the next release has to be 2.0.5 I would like to make an alternative
> proposal, which would include
> - stabilization of current 2.0.4
> - making all API changes to allow freezing them post 2.0.5
> And nothing else.
>
> We can add new features in subsequent release (release). Potentially we
> can end up in the same place as you proposed but with more certainty along
> the road.
> The main reason I am asking for stabilization is to make it available for
> large installations such as Yahoo sooner. And this will require commitment
> to compatibility as Bobby mentioned on several occasions.
>
> As a rule of thumb compatibility for me means that I can do a rolling
> upgrade on the cluster. More formal definitions like Karthik's
> Compatibility page are better. BigTop's integration testing proved to be
> very productive.
>
> Thanks,
> --Konstantin
>
>
> On Fri, Apr 26, 2013 at 6:06 PM, Arun C Murthy <[EMAIL PROTECTED]>wrote:
>
>> Konstantin,
>>
>> On Apr 26, 2013, at 4:34 PM, Konstantin Shvachko wrote:
>>
>> > Do you think we can call the version you proposed to release
>> > 2.1.0 or 2.1.0-beta?
>> >
>> > The proposed new features imho do not exactly conform with the idea
>> > of dot-dot release, but definitely qualify for a major number change.
>> > I am just trying to avoid rather ugly 2.0.4.1 versions, which of course
>> > also possible.
>>
>> I'm agnostic to the schemes.
>>
>> During the long discussion we had just 2 months ago, I proposed that
>> 2.1.x be the beta series initially.
>>
>> The feedback and consensus was that it wasn't the right numbering scheme:
>> http://s.apache.org/1j4
>>
>> thanks,
>> Arun
>>
>
>
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