Hi Lars, #2, does it mean you will stop back-porting the new features when it will become a "long-term" release? If so, I'm for option #2...
JM In your option 2013/3/1 Enis Söztutar <[email protected]>: > Thanks Lars, I think it is a good listing of the options we have. > > I'll be +1 for #1 and #2, with #1 being a preference. > > Enis > > > On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[email protected]> wrote: > >> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we >> have three options: >> 1. Backport new features to 0.94 as we see fit as long as we do not >> destabilize 0.94. >> 2. Declare a certain point release (0.94.6 looks like a good candidate) as >> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6 >> tag) and than create 0.94.6.x fix only releases. I would volunteer to >> maintain a 0.94.6 branch in addition to the 0.94 branch. >> 3. Categorically do not backport new features into 0.94 and defer to 0.95. >> >> I'd be +1 on option #1 and #2, and -1 on option #3. >> >> -- Lars >> >> >> >> ________________________________ >> From: Jonathan Hsieh <[email protected]> >> To: [email protected]; lars hofhansl <[email protected]> >> Sent: Friday, March 1, 2013 3:11 PM >> Subject: Re: [DISCUSS] More new feature backports to 0.94. >> >> I think we are basically agreeing -- my primary concern is bringing new >> features in vital paths introduces more risk, I'd rather not backport major >> new features unless we achieve a higher level of assurance through system >> and basic fault injection testing. >> >> For the three current examples -- snapshots, zk table locks, online merge >> -- I actually would prefer not including any in apache 0.94. Of the bunch, >> I feel the table locks are the most risky since it affects vital paths a >> user must use, where as snapshots and online merge are features that a >> user could choose to use but does not necessarily have to use. I'll voice >> my concerns, reason for concerns, and justifications on the individual >> jiras. >> >> I do feel that new features being in a dev/preview release like 0.95 aligns >> well and doesn't create situations where different versions have different >> feature sets. New features should be introduced and hardened in a >> dev/preview version, and the turn into the production ready versions after >> they've been proven out a bit. >> >> Jon. >> >> 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] >> > >> >> >> >> -- >> // Jonathan Hsieh (shay) >> // Software Engineer, Cloudera >> // [email protected] >>
