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. >>>
