Thanks Andrew. I think there are others too who have the same predicament (Francis Liu for instance). Backports of perf improvements, bug fixes, and operational tooling improvements makes sense while branch-1 is in active use.
I appreciate Allans' sentiment. It is time to move the stable pointer from branch-1 to branch-2, say branch-2.1.2? S On Sun, Jan 20, 2019 at 10:14 PM Andrew Purtell <[email protected]> wrote: > I can speak for myself and assume others backporting to branch-1 have > similar motivations. We are backporting interesting and useful and > reasonable improvements, because branch-1 is still useful and in > production, and will be for the foreseeable future. Changes like perf > improvements and operability/tooling/UI improvements should not be denied > to branch-1 users if some contributors and committers are putting in the > effort to maintain it. I agree major new features should not be backported. > I doubt anyone will try to backport AMv2 or IMC. I won’t, for sure. Not > interested in destabilizing change. > > Personally I work for an organization that runs branch-1 derived code in > production. You can stop my maintenance activities in the community but > that would just mean I make a fork and take the work internal. Why not let > me contribute these efforts back to the community? It is your choice. I > don't see why we can't have activity both in branch-1 and branch-2. To each > their own. Let the community organically decide what is right by do-ocracy. > > If you ask me why aren’t we using branch-2 now, I have to say > unfortunately it’s not production ready for us. Refer to the recent > discussion about hbck2 for one concern. Another is a colleague did a > trivial test with head of branch-2 and measured a 50% perf degradation in > scan performance. Now, that is just a one off test. But it causes concern. > We are swamped already with run the business concerns. We can’t take on the > additional risk at this time. Perhaps in the future we will have more > bandwidth to contribute to branch-2 efforts. > > > On Jan 20, 2019, at 9:29 PM, Allan Yang <[email protected]> wrote: > > > > {quote} > > For example, you release 2.1.0 yesterday, 1.5.0 today, and then 2.1.1 > > tomorrow, it is OK that 2.1.0 does not have all feature which 1.5.0 has, > > but 2.1.1 should have all features which 1.5.0 has. > > {quote} > > I don't think can work, normal user mostly won't care about the release > > time, they only know 2.1.1 > 2.1.0 > 1.5.0. They will think higher > version > > includes all the feature in lower version. > > > > I don't get the point why we are now still backporting new features from > > branch-2 to branch-1. Yes, there is many 1.x cluster in production, so we > > need to release 1.x versions to fix bugs and keep them stable, as the > > stable point is still in 1.x. > > And at the same time, we should try to move on to 2.x, making branch-1 > as a > > bugfix branch for sometime before deprecating it. As far as I see, > branch-1 > > is still very 'active', too active I think. > > If we stop backport features from branch-2 to branch-1, then there is no > > problem, IMHO. > > Best Regards > > Allan Yang > > > > > > Andrew Purtell <[email protected]> 于2019年1月20日周日 上午5:27写道： > > > >> As branch RM for branch-1 I will always check to make sure a commit > there > >> has first been committed to branch-2. There will always be an upgrade > path > >> from a branch-1 based release to a branch-2 based release. The relevant > >> JIRAs will either have a 1.x and 2.x fixVersion or the backport JIRA > will > >> be linked to the one for the branch-2 commit. When making the release > notes > >> we will be looking at these things (or should, anyway). We can update > the > >> upgrade paths documentation whenever we find this kind of linkage. > Perhaps > >> we can describe this for future RMs in the how to release section of the > >> doc? Does this satisfy the concerns? > >> > >>> On Jan 18, 2019, at 11:47 PM, Sean Busbey <[email protected]> wrote: > >>> > >>> I agree with Andrew that we can't both have maintenance releases and > >> expect > >>> every feature in ongoing branch-1 releases to be in branches-2.y. > >>> > >>> Tracking consideration for when features are available across major > >>> versions fits in well with the "upgrade paths" section in the ref > guide. > >>> > >>> We've just gotten in the habit of it only getting filled in when a big > >>> release is coming up. > >>> > >>> > >>> > >>>> On Fri, Jan 18, 2019, 23:46 张铎(Duo Zhang) <[email protected] > wrote: > >>>> > >>>> Then we must have a upgrade path, for example, 1.5.x can only be > >> upgraded > >>>> to 2.2.x if you want all the features still there? > >>>> > >>>> Maybe we should have a release timeline for the first release of all > the > >>>> minor releases? So when user want to upgrade, they can choose the > minor > >>>> release which is released later than the current one. > >>>> > >>>> Andrew Purtell <[email protected]>于2019年1月19日 周六13:15写道： > >>>> > >>>>> Also I think branch-1 releases will be done on a monthly cadence > >>>>> independent of any branch-2 releases. This is because there are > >> different > >>>>> RMs at work with different needs and schedules. > >>>>> > >>>>> I can certainly help out some with branch-2 releasing if you need it, > >>>>> FWIW. > >>>>> > >>>>> It may also help if we begin talking about 1.x and 2.x as separate > >>>>> "products". This can help avoid confusion about features in 1.5 not > in > >>>> 2.1 > >>>>> but in 2.2. For all practical purposes they are separate products. > Some > >>>> of > >>>>> our community develop and run branch-1. Others develop and run > >> branch-2. > >>>>> There is some overlap but the overlap is not total. The concerns will > >>>>> diverge a bit. I think this is healthy. Everyone is attending to what > >>>> they > >>>>> need. Let's figure out how to make it work. > >>>>> > >>>>>> On Jan 18, 2019, at 9:04 PM, Andrew Purtell < > [email protected] > >>> > >>>>> wrote: > >>>>>> > >>>>>> Also please be prepared to support forward evolution and maintenance > >> of > >>>>> branch-1 for, potentially, years. Because it is used in production > and > >>>> will > >>>>> continue to do so for a long time. Features may end up in 1.6.0 that > >> only > >>>>> appear in 2.3 or 2.4. And in 1.7 that only appear in 2.5 or 2.6. This > >>>>> shouldn't be confusing. We just need to document it. JIRA helps some, > >>>>> release notes can help a lot more. Maybe in the future a feature to > >>>> version > >>>>> matrix in the book. > >>>>>> > >>>>>>> On Jan 18, 2019, at 8:59 PM, Andrew Purtell < > >> [email protected] > >>>>> > >>>>> wrote: > >>>>>>> > >>>>>>> This can't work, because we can put things into a new minor that > >>>> cannot > >>>>> go into a patch relesse. If you say instead 2.2.0 must have > everything > >> in > >>>>> 1.5.0, it can work. The alignment of features should happen at the > >> minor > >>>>> releases. If we can also have alignment in patch releases too, that > >> would > >>>>> be great, but can't be mandatory. > >>>>>>> > >>>>>>>> On Jan 18, 2019, at 7:12 PM, 张铎(Duo Zhang) <[email protected] > > > >>>>> wrote: > >>>>>>>> > >>>>>>>> Please see the red words carefully, I explicitly mentioned that, > the > >>>>> newer > >>>>>>>> version should be released LATER, if you want to get all the > >>>> features. > >>>>>>>> > >>>>>>>> For example, you release 2.1.0 yesterday, 1.5.0 today, and then > >> 2.1.1 > >>>>>>>> tomorrow, it is OK that 2.1.0 does not have all feature which > 1.5.0 > >>>>> has, > >>>>>>>> but 2.1.1 should have all features which 1.5.0 has. > >>>>>>>> > >>>>>>>> Sergey Shelukhin <[email protected]> > >>>>> 于2019年1月19日周六 > >>>>>>>> 上午10:23写道： > >>>>>>>> > >>>>>>>>> Consider that we actually cannot guarantee this without a time > >>>>> machine, > >>>>>>>>> because some "newer" versions are already released. > >>>>>>>>> > >>>>>>>>> If we backport to 1.5 now, we cannot do anything about 2.0.0, > >> 2.1.0, > >>>>>>>>> 2.1.2, etc. because they are already released... if the user > >>>> upgrades > >>>>> from > >>>>>>>>> 1.5 to 2.0.1 for example, they will lose the feature no matter > >> what. > >>>>>>>>> The only way to ensure is to > >>>>>>>>> - always update to latest dot version, > >>>>>>>>> - also for us to make sure we never release before releasing > every > >>>>> "later" > >>>>>>>>> dot release (e.g. we cannot release 1.5 before 2.1.3, 2.0.N, etc. > >> so > >>>>>>>>> there's the latest release for every line). > >>>>>>>>> - and also for us to make sure that every single dot line > actually > >>>>> has a > >>>>>>>>> release - when e.g. 2.0.X line is abandoned that may not happen, > so > >>>>> the > >>>>>>>>> latest version of 2.0.X will precede latest 1.Y because 1.Y may > >>>> still > >>>>> be > >>>>>>>>> active (like as far as I recall 0.94 was getting dot releases > even > >>>>> when > >>>>>>>>> 0.96 was abandoned) - so even if the user goes from 1.Y to the > >>>> latest > >>>>> 2.0.X > >>>>>>>>> they will lose the feature. > >>>>>>>>> > >>>>>>>>> I think this is kind of expected... I agree that it needs to be > >>>>>>>>> documented. To an extent it already is in JIRA where fixVersion > may > >>>> be > >>>>>>>>> "3.0, 2.2, 1.5", but it makes sense to document explicitly. > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: 张铎(Duo Zhang) <[email protected]> > >>>>>>>>> Sent: Friday, January 18, 2019 5:50 PM > >>>>>>>>> To: HBase Dev List <[email protected]> > >>>>>>>>> Subject: About how features are integrated to different HBase > >>>> versions > >>>>>>>>> > >>>>>>>>> I think we have a good discussion on HBASE-21034, where a feature > >> is > >>>>> back > >>>>>>>>> ported to branch-1, but then folks think that we should not back > >>>> port > >>>>> them > >>>>>>>>> to branch-2.1 and branch-2.0, as usually we should not add new > >>>>> features to > >>>>>>>>> minor release lines. > >>>>>>>>> > >>>>>>>>> I think the reason why we do not want the feature in branch-2.1 > and > >>>>>>>>> branch-2.0 is reasonable, but this will introduce another > problem. > >>>> As > >>>>>>>>> later, we will release a 1.5.0 which has the feature, but when a > >>>> user > >>>>> later > >>>>>>>>> upgrades from 1.5.0 to 2.1.x or 2.0.x, it will find that the > >> feature > >>>>> is > >>>>>>>>> gone, even though the 2.1.x or 2.0.x is released after 1.5.0 is > >>>>> released, > >>>>>>>>> as we do not port the feature to these two branches. This will be > >>>> very > >>>>>>>>> confusing to users I'd say. > >>>>>>>>> > >>>>>>>>> So I think we should guarantee that, a higher version of HBase > >>>> release > >>>>>>>>> will always contain all the features of a HBase release with a > >> lower > >>>>>>>>> version which is released earlier, unless explicitly > mentioned(for > >>>>> example, > >>>>>>>>> DLR). > >>>>>>>>> > >>>>>>>>> And this implies that, when we setup a new major release and > make a > >>>>> new > >>>>>>>>> release on the first minor release line, then the develop branch > >> for > >>>>> the > >>>>>>>>> previous major release will be useless, as said above, usually we > >> do > >>>>> not > >>>>>>>>> want to port any new features to the minor release line of the > new > >>>>> major > >>>>>>>>> release, then the new features should not be ported to previous > >>>> major > >>>>>>>>> release, otherwise we will break the guarantee above. And this > also > >>>>> means > >>>>>>>>> that, we could just use the 'develop' branch to make new > releases. > >>>>>>>>> > >>>>> > >>>> > >> >
