And yes we should document this. And also we need to have a web page to list all the releases in timeline? So user could know which version is safe to use when upgrading easily.
张铎(Duo Zhang) <palomino...@gmail.com> 于2019年1月19日周六 上午11:12写道： > 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. >> >
