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) <palomino...@gmail.com> 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 <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? > > > >
