Re: Handling of fixVersion for umbrella tasks
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, 张铎 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 于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) wrote: >> >>> You should only remove 2.6.0 when fix versions = 2.5.0 :) >>> Bryan Beaudreault 于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, 张铎 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
Re: Handling of fixVersion for umbrella tasks
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 于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) wrote: > > > You should only remove 2.6.0 when fix versions = 2.5.0 :) > > > > Bryan Beaudreault 于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, 张铎 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 于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
Re: Handling of fixVersion for umbrella tasks
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) wrote: > You should only remove 2.6.0 when fix versions = 2.5.0 :) > > Bryan Beaudreault 于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, 张铎 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 于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? > > >> > > > > > >
Re: Handling of fixVersion for umbrella tasks
You should only remove 2.6.0 when fix versions = 2.5.0 :) Bryan Beaudreault 于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 > > > 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, 张铎 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 于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? > >> > > >
Re: Handling of fixVersion for umbrella tasks
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 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 > 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, 张铎 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 于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? >> >
