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 <ecl...@apache.org>: > 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 <la...@apache.org> 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 <j...@cloudera.com> >> To: dev@hbase.apache.org >> 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 >> // j...@cloudera.com >>
