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