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 <bbeaudrea...@apache.org> 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) <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? > > > > > > >
