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

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


+
Jonathan Hsieh 2013-03-01, 16:31
+
lars hofhansl 2013-03-01, 19:00
+
Elliott Clark 2013-03-01, 22:43
+
Jean-Marc Spaggiari 2013-03-01, 23:12
Copy link to this message
-
Re: [DISCUSS] More new feature backports to 0.94.
I think we have discussed this before, and your concerns are valid.

In the snapshot backporting discussions, I have proposed to do fork 94, and
add snapshots on top of it, and make a release called 0.95 (0.95 wasn't
being used back then). The conclusion from those discussions was that, if I
remember correctly, that if there will be significant testing from HW+C,
then we might be ok with the backport. The key point from those discussions
was that since 96 is so late, we only have 94 as the only stable target
that features like table locks, snapshots, merge, etc (which are orthogonal
to wire compat) can be delivered to users in a timely maner. The current
situation with 94 is an exception, rather than the norm, because we could
not deliver stable releases for the new features for such a long time.
Since 96 is still at least 2-3 months ahead, if we want to deliver
snapshots, table locks, etc, 94 is the place.

The only alternative I can see is to fork 94 branch, and add the new
features there. We can call it 94-snapshots branch, and have releases from
there, as well as releases from plain 94.

Enis
On Fri, Mar 1, 2013 at 3:12 PM, Jean-Marc Spaggiari <[EMAIL PROTECTED]
> wrote:

> 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]>
> >> To: [EMAIL PROTECTED]
> >> Sent: Friday, March 1, 2013 8:31 AM
+
Jonathan Hsieh 2013-03-01, 23:11
+
lars hofhansl 2013-03-02, 02:10
+
Enis Söztutar 2013-03-02, 02:17
+
Jean-Marc Spaggiari 2013-03-02, 02:25
+
Ted Yu 2013-03-02, 02:24
+
Andrew Purtell 2013-03-03, 13:50
+
Ted 2013-03-03, 14:12
+
Andrew Purtell 2013-03-03, 14:38
+
Jean-Marc Spaggiari 2013-03-04, 13:41
+
Stack 2013-03-04, 21:27
+
Enis Söztutar 2013-03-04, 22:29
+
Andrew Purtell 2013-03-05, 01:57
+
Dave Wang 2013-03-01, 16:38
+
Lars Hofhansl 2013-03-02, 02:46
+
Enis Söztutar 2013-03-02, 02:54
+
Jean-Marc Spaggiari 2013-03-02, 03:12
+
lars hofhansl 2013-03-02, 03:24
+
Ted Yu 2013-03-02, 03:30
+
lars hofhansl 2013-03-02, 03:44
+
Nicolas Liochon 2013-03-02, 11:43
+
Ted 2013-03-02, 11:57
+
Jonathan Hsieh 2013-03-02, 15:36
+
lars hofhansl 2013-03-02, 16:47
+
Ted Yu 2013-03-02, 16:14
+
Jonathan Hsieh 2013-03-02, 16:26
+
lars hofhansl 2013-03-02, 20:46
+
Jonathan Hsieh 2013-03-02, 21:49
+
Stack 2013-03-02, 23:24
+
lars hofhansl 2013-03-02, 03:23
+
Lars Hofhansl 2013-03-02, 02:45