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 <bus...@apache.org> 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) <palomino...@gmail.com 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 <andrew.purt...@gmail.com>于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 <andrew.purt...@gmail.com> >>> 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 <andrew.purt...@gmail.com >>> >>> 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) <palomino...@gmail.com> >>> 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 <sergey.sheluk...@microsoft.com.invalid> >>> 于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) <palomino...@gmail.com> >>>>>>> Sent: Friday, January 18, 2019 5:50 PM >>>>>>> To: HBase Dev List <dev@hbase.apache.org> >>>>>>> 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. >>>>>>> >>> >>
