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

Switch to Threaded View
HBase >> mail # dev >> [DISCUSS] More new feature backports to 0.94.

Copy link to this message
Re: [DISCUSS] More new feature backports to 0.94.
I also think also that new features need to go in new versions only
and try to avoid backporting them.. Else if we keep adding new
features in previous versions, we might have to keep adding bug fixes
because of those features and it's a never ending story.

But as Elliott is saying, we need to push the fixes in all the branchs
and not only the trunk to not force people to migrate to new major
releases to get some bugs fixed.

The postgresql versionning policy is nice. But I'm not sure we should
keep 4 versions running. 4 version will mean we still need to backport
fixes to 0.90.x even when 0.96 will be out. I'm not sure it's
realistic since there is to much differences between all those
versions. I will say 2 to 3 is the max. Like when a version is recent
we can keep 3 versions going, but when the versions is not to its
x.x.4 ou x.x.5, it's supposed to be stable enought and we can think
about stopping the support for the 3 versions and move to 2.

With today versions that will mean that we support 0.92.x and 0.94.x
since we are at 0.94.5. And we will continue to support 0.92.x until
0.96 is up to 0.96.4.

Just my opinion.

2013/3/1 Elliott Clark <[EMAIL PROTECTED]>:
> I'm worried about users who are starting to use 0.94.x.  If they have a bug
> in that version, and it's fixed or they submit a patch to fix it.  Then
> they should have a version to upgrade to that includes that bug fix and
> doesn't include other new features.   I don't think that many people will
> want to upgrade their production database to new feature and code when
> trying to fix a bug.
> Something like http://www.postgresql.org/support/versioning/ seems very
> similar to what I would envision.  Only major versions contain new
> features.  We're not at a place that the community sees a 1.0.0 as
> realistic so we don't have the first number to play with.  I don't think
> that changes the fact that the last number should in my opinion be reserved
> for patch releases.
> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> This is an open source project, as long as there is a volunteer to
>> backport a patch I see no problem with doing this.
>> The only thing we as the community should ensure is that it must be
>> demonstrated that the patch does not destabilize the 0.94 code base; that
>> has to be done on a case by case basis.
>> Also, there is no stable release of HBase other than 0.94 (0.95 is not
>> stable, and we specifically state that it should not be used in production).
>> -- Lars
>> ________________________________
>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> Sent: Friday, March 1, 2013 8:31 AM
>> Subject: [DISCUSS] More new feature backports to 0.94.
>> I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
>> saw HBASE-7965 which suggests porting some major-ish features (table locks,
>> online merge) in to the apache 0.94 line.   We should chat about what we
>> want to do about new features and bringing them into stable versions (0.94
>> today) and in general criteria we use for future versions.
>> This is similar to the snapshots backport discussion and earlier backport
>> discussions.  Here's my understanding of  high level points we basically
>> agree upon.
>> * Backporting new features to the previous major version incurs more cost
>> when developing new features,  pushes back efforts on making the trunk
>> versions and reduces incentive to move to newer versions.
>> * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
>> reasonable since they are generally less stable.
>> * Backporting new features to later version (0.9x.5, 0.9x.6) is less
>> reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
>> features).
>> * Backporting orthogonal features (snapshots) seems less risky than core
>> changing features
>> * An except: If multiple distributions declare intent to backport, it makes
>> sense to backport a feature. (snapshots for example).