I checked the history a bit... For 2.0.0, the previous version is 1.0.0...
https://github.com/apache/hbase/blob/branch-2.0/CHANGES.md For 2.1.0 and 2.2.0, we do not include the previous version in the CHANGES.md, but you can pick some issues, usually it will have a 2.0.x or 2.1.x fix versions. And for 2.3.0 https://github.com/apache/hbase/blob/branch-2.3/CHANGES.md We set 2.2.0 as the previous version. And for 2.4.0 https://github.com/apache/hbase/blob/branch-2.4/CHANGES.md We set 2.3.0 as the previous version. And after consideration, I think why in the past we usually choose to based on .0 is reasonable, as we can make sure that all the commits to 2.5.0 will also go into 2.6.0, but not all the commits in 2.5.1 will go into 2.6.0, even if 2.6.0 is released after 2.5.1. For example, maybe we use different ways to fix something in branch-2.5 and branch-2.6, as 2.5 is a patch release you can not break things but on 2.6, you can do a cleaner fix. Thanks. Bryan Beaudreault <bbeaudrea...@apache.org> 于2024年1月23日周二 18:58写道： > > Thanks again for the back and forth here, both. It seems like there is no > single right solution, which in my opinion is not great. It’s > understandable though because historically it’s been hard to enforce a > standard. > > The release process is involved but largely automated. One piece not > automated yet is this fixVersion audit. Automating this part of the release > process could be the enforcement we need to keep a standard. We have much > of the foundation of such an automation in Nick’s python script, I could > supply the rest. > > It seems like we need to agree on which previous version to root a > changelog to. Personally I prefer the last minor release because that seems > most intuitive to a user. If we assume good “upgrade hygiene”, people are > more likely to be upgrading from some patch release than the last full > minor release, at least in the way hbase releases work today. If someone is > upgrading from an older release, they can more easily create a full > changelog for their upgrade by adding up the changelogs between their > current and target. If we root in the last minor release they have to do > more work to filter out changes they already have. > > Perhaps I should raise a VOTE or clean DISCUSS thread to reach consensus on > which approach to take. With that in hand, we can automate it. > > In terms of SFT/backports, I agree but lacking any enforcement I think we > probably mess this up often. > https://issues.apache.org/jira/browse/HBASE-26639 is an example where it > was directly cherry-picked so should have 2.5.0 fixVersion but doesn’t. Not > sure it’s worth fixing this now, but a script can easily detect it going > forward. > > > On Mon, Jan 22, 2024 at 11:15 PM Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > > If you use 2.5.7 as the previous version of the 2.6.0 release then only > > the changes committed to branch-2.6 not also committed to branch-2.5 at > > time of release need a fixVersion of 2.6.0. This can be analyzed with a > > compare tool looking at the respective branches while ignoring any commits > > on branch-2.5 more recent than the 2.5.7 release. The git log is the source > > of truth not a JIRA fixVersion. So you’d be ignoring 2.5.8 or any stray > > nonsense implicitly. > > > > If you use 2.5.0 as the previous version for the 2.6.0 release as Duo > > suggests it’s pretty much the same analysis except the comparison must > > ignore any commits on branch-2.5 with a date newer than the 2.5.0 release > > date. Larger change file. More work. > > > > Either option makes sense to me for different reasons. > > > > For SFT, or any other backport, if the backport was done with a simple > > cherry pick then the original JIRA id goes into the changes file. If it was > > done with a backport JIRA and modified or new commit message referencing > > said backport JIRA, then the id of the backport JIRA goes into the changes > > file. I think the result then will cause the least surprise. > > > > It has been so long I don’t recall why the 2.5.0 changes file is based on > > 2.2.0. Earlier in this thread I remembered this detail incorrectly. What I > > described is what I did for 2.4.0 (based on a 2.3 changes file), not 2.5.0. > > It looks like by the time we did 2.5.0 we were using the auto doc tooling. > > > > > On Jan 22, 2024, at 6:58 PM, 张铎 <palomino...@gmail.com> wrote: > > > It is based on how you construct the CHANGES.md. > > > > > > If in the CHANGES.md, your previous version is 2.5.0, then you should > > > include all the issues committed to branch-2.6 which are not included > > > in 2.5.0. If your previous version is 2.5.7, then you should include > > > the issues from 2.5.7. > > > > > > For me, I think the previous version for 2.6.0 should be 2.5.0. > > > > > > BTW, the CHANGES.md for branch-2.5 seems a bit strange, the previous > > > version for 2.5.0 is 2.2.0... > > > > > > https://github.com/apache/hbase/blob/branch-2.5/CHANGES.md > > > > > > Bryan Beaudreault <bbeaudrea...@apache.org> 于2024年1月23日周二 07:54写道： > > >> > > >> Ok I can do that but I don’t think that’s quite what Andrew described, > > >> unless I misunderstood. > > >> > > >> On Mon, Jan 22, 2024 at 6:28 PM 张铎(Duo Zhang) <palomino...@gmail.com> > > wrote: > > >> > > >>> You should only remove 2.6.0 when fix versions = 2.5.0 :) > > >>> Bryan Beaudreault <bbeaudrea...@apache.org>于2024年1月23日 周二06:32写道： > > >>>> Andrew, I'd like to clarify something before I act -- > > >>>> I have a script which has identified 300+ jiras where fixVersion is > > >>> 2.6.0, > > >>>> but the commit exists in branch-2.5. Most of those have a fixVersion < > > >>>> 2.5.8. Here's a couple examples: > > >>>> - https://issues.apache.org/jira/browse/HBASE-28245 -- has 2.6.0 and > > >>> 2.5.7 > > >>>> - https://issues.apache.org/jira/browse/HBASE-27407 -- has 2.6.0 and > > >>> 2.5.1 > > >>>> For those, I plan to remove the 2.6.0 fixVersion. Correct? > > >>>> There are 22 of the above jiras whose 2.5.x fixVersion is 2.5.8, > > which is > > >>>> unreleased. For those, I should leave 2.6.0 fixVersion alone. Correct? > > >>>> Finally, I wonder how we should handle all of the many SFT jiras which > > >>> were > > >>>> backported to 2.5. For example: > > >>>> https://issues.apache.org/jira/browse/HBASE-26639. This jira exists > > in > > >>>> branch-2.5, but _does not_ have a 2.5.0 fixVersion and _does_ have a > > >>> 2.6.0 > > >>>> fixVersion. I wish those had been given a fixVersion of 2.5.x when > > they > > >>>> were cherry-picked. I presume I should leave these alone, but I don't > > >>> love > > >>>> the inconsistency of it. Since I plan to do all of these updates with > > a > > >>>> script if possible, I could potentially fix these. > > >>>> Thanks for the guidance. > > >>>> On Tue, Jan 16, 2024 at 12:54 PM Bryan Beaudreault < > > >>>> bbeaudrea...@apache.org> > > >>>> wrote: > > >>>>> Thank you both for the input. That's a good idea Andrew, I'll take a > > >>> stab > > >>>>> at it. > > >>>>> I have a script (based on Nick's git-jira-release-audit [1]) which > > I'm > > >>>>> using to audit versions. I'll see if I can add this to that so we can > > >>>>> automate that cleanup for future .0 releases. > > >>>>> [1] > > >>> > > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit > > >>>>> On Sun, Jan 14, 2024 at 8:50 PM Andrew Purtell < > > >>> andrew.purt...@gmail.com > > >>>>> wrote: > > >>>>>> For 2.5.0 I based the change log on the change log of what was then > > >>> the > > >>>>>> last/most recent 2.4 release. Anything committed into 2.4 with a fix > > >>>>>> version of 2.5, I dropped the 2.5 fix version. The 2.5 fix version > > was > > >>>> kept > > >>>>>> for anything novel in 2.5. The result was an orderly cumulative > > change > > >>>> log. > > >>>>>> I also audited the commit history to make sure no change was > > committed > > >>>> to > > >>>>>> 2.4 and not 2.5. This took quite a bit of time. I do not think it > > can > > >>> be > > >>>>>> avoided but needs be done only for the .0 release. > > >>>>>>> On Jan 14, 2024, at 2:37 AM, 张铎 <palomino...@gmail.com> wrote: > > >>>>>>> Usually we will only set fix version if there is a commit. > > >>>>>>> The only exception is for some umbrella issues where we want to put > > >>> a > > >>>>>>> fat release note there, such as HBASE-26067. > > >>>>>>> This will introduce some difficulties to the RMs as it will cause > > >>>>>>> mismatches on the commit history and CHANGES.md. But anyway, you > > >>> need > > >>>>>>> to manually check the issue if it is missed in the commit history, > > >>> if > > >>>>>>> it is an umbrella issue like HBASE-26067, you can just ignore it. > > >>>>>>> Thanks. > > >>>>>>> Bryan Beaudreault <bbeaudrea...@apache.org> 于2024年1月14日周日 09:27写道： > > >>>>>>>> Hi Devs, > > >>>>>>>> I'm working on auditing the 2.6.0 fixVersion JIRAs in prep for the > > >>>>>> RC0. One > > >>>>>>>> thing I'm noticing is there are a couple umbrella JIRAs which have > > >>>>>>>> fixVersion of 2.6.0 but no corresponding commit in the branch. > > This > > >>>> is > > >>>>>>>> because all of the work was done in sub-tasks, and those sub-tasks > > >>>> are > > >>>>>> in > > >>>>>>>> the branch. Here's an example: > > >>>>>>>> https://issues.apache.org/jira/browse/HBASE-26067 > > >>>>>>>> I'm curious how we want to handle this. On the one hand it seems > > >>> good > > >>>>>> to be > > >>>>>>>> able to 1-to-1 link JIRA fixVersion to commits in branches. On the > > >>>>>> other > > >>>>>>>> hand, umbrella are useful aggregators and can be nice for > > >>>> consolidating > > >>>>>>>> release notes. > > >>>>>>>> Maybe the audit tool I'm working with can just ignore umbrella, or > > >>>>>> maybe > > >>>>>>>> umbrella tasks should be handled in a feature branch and > > eventually > > >>>>>> merged > > >>>>>>>> in with the umbrella jira ID. > > >>>>>>>> Thoughts? > >
