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