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 > 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). > > Some new circumstances and discussion topics: > * We now have a dev branch (0.95) with looser compat requirements that we > could more readily release with dev/preview versions. Shouldn't this > reduce the need to backport features to the apache stable branches? Would > releases of these releases "replace" the 0.x.0 or 0.x.1 releases? > * For major features in later versions we should raise the bar on the > amount of testing probably be more explicit about what testing is done > (unit tests not suffcient, system testing stories/resports a requirement). > Any other suggestions? > > Jon. > > -- > // Jonathan Hsieh (shay) > // Software Engineer, Cloudera > // [email protected] >
