Re: Handling of fixVersion for umbrella tasks
Would love another discuss thread on that tangent, because I completely agree and think it warrants some discussion. In terms of the original takeaways here, I'm now auditing the jiras which have fixVersion = 2.6.0 but which existed in branch-2.5 prior to the release of 2.5.0. There are only 31 of them, and 28 are SFT direct cherry-picks that should have had fixVersion 2.5.0 added. The remaining 3 also should have had fixVersion 2.5.0. I'd prefer to update jira to replace 2.6.0 with 2.5.0 for these, but want to give you all the chance to disagree. Almost done on this topic, thanks for bearing with me :) On Tue, Jan 23, 2024 at 1:54 PM Nick Dimiduk wrote: > I’m late to the discussion, but you’ve concluded on what I believe is the > correct approach. Another way to consider why this approach is correct is > to think in terms of “git time” instead of chronological time. Consider the > last common ancestor commit in the git histories. branch-2.6 was created > from branch-2. The most recent release (in terms of “git time”) that is > closest to that branch point was 2.5.0. > > Tangentially relevant: this is part of why our master branch is such a > burden — we barely ever release from that git history. Its most recent > common ancestor release tag probably predates my participation in the > project. I think this makes a strong argument in favor of lazily branching > the next major release line off of the most recent major release line and > deleting master entirely. It’s counter-productive to commit a change to > master and then not release it for 5 years. Sure, a back-port of the > feature might eventually release, but then what was the point of the commit > to master in the first place? If this strategy is bad for some other > reason, I’d love to see a process by which we can get to regular releases > off of whatever is our default development branch. > > Thanks, > Nick > > On Tue, 23 Jan 2024 at 14:16, Bryan Beaudreault > wrote: > > > Thanks for the history dive :) > > > > > 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. > > > > I actually had the same thought after sending my last response. There > might > > also be bug fixes that only apply to 2.5.x. This, along with historical > > convention, seems like a good reason to keep it based on the last minor > > release. I'll update my auditing based on that and see if there's a doc > > improvement I can do here at some point too. > > > > On Tue, Jan 23, 2024 at 6:20 AM 张铎(Duo Zhang) > > wrote: > > > > > 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 于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
Re: Handling of fixVersion for umbrella tasks
I’m late to the discussion, but you’ve concluded on what I believe is the correct approach. Another way to consider why this approach is correct is to think in terms of “git time” instead of chronological time. Consider the last common ancestor commit in the git histories. branch-2.6 was created from branch-2. The most recent release (in terms of “git time”) that is closest to that branch point was 2.5.0. Tangentially relevant: this is part of why our master branch is such a burden — we barely ever release from that git history. Its most recent common ancestor release tag probably predates my participation in the project. I think this makes a strong argument in favor of lazily branching the next major release line off of the most recent major release line and deleting master entirely. It’s counter-productive to commit a change to master and then not release it for 5 years. Sure, a back-port of the feature might eventually release, but then what was the point of the commit to master in the first place? If this strategy is bad for some other reason, I’d love to see a process by which we can get to regular releases off of whatever is our default development branch. Thanks, Nick On Tue, 23 Jan 2024 at 14:16, Bryan Beaudreault wrote: > Thanks for the history dive :) > > > 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. > > I actually had the same thought after sending my last response. There might > also be bug fixes that only apply to 2.5.x. This, along with historical > convention, seems like a good reason to keep it based on the last minor > release. I'll update my auditing based on that and see if there's a doc > improvement I can do here at some point too. > > On Tue, Jan 23, 2024 at 6:20 AM 张铎(Duo Zhang) > wrote: > > > 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 于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
Re: Handling of fixVersion for umbrella tasks
Thanks for the history dive :) > 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. I actually had the same thought after sending my last response. There might also be bug fixes that only apply to 2.5.x. This, along with historical convention, seems like a good reason to keep it based on the last minor release. I'll update my auditing based on that and see if there's a doc improvement I can do here at some point too. On Tue, Jan 23, 2024 at 6:20 AM 张铎(Duo Zhang) wrote: > 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 于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
Re: Handling of fixVersion for umbrella tasks
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 于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 > 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, 张铎 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
Re: Handling of fixVersion for umbrella tasks
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 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, 张铎 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 >
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? >> >
Re: Handling of fixVersion for umbrella tasks
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
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
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?
