I have used JQL searches and git log inspection previously but will be trying out our git-jira-release-audit tool this time. After populating the local DB from git and JIRA for the three respective versions, SQL query against the generated SQLite file should be convenient.
> > On Mar 21, 2022, at 3:53 AM, Nick Dimiduk <[email protected]> wrote: > > I have also been doing as Andrew, whether it is the right thing or not. I > think Duo is correct in that until 2.5.0, a commit to both branch-2.5 and > branch-2 should only be marked as 2.5.0. This should be easy enough to fix > -- once 2.5.0 is released, we can search Jira for all issues with > fixVersion in (2.5.0, 2.6.0) and remove the 2.6.0 label. > > If you are starting the 2.5.0 release notes from the most recent 2.4.x > release, then a similar cleanup can be done for 2.5.0, by searching for all > issues in 2.4.x that also have 2.5.0 fixVersion, and removing 2.5.0. I am > not sure what our release automation supports in this regard. > >> On Sun, Mar 20, 2022 at 6:40 PM Andrew Purtell <[email protected]> >> wrote: >> >> Per the earlier discussion, to be comprehensive, there is also this rule: >> >> 4. If a change is in branch-2.4, branch-2.5, and branch-2: fix version = >> 2.4.x, the version the change was released in. (Fix versions 2.5.0 and >> 2.6.0 will be dropped for already released changes.) >> >> The 2.5.0 change log will be based on that of the most recent 2.4.x >> release. 2.4.0’s change log was based on that of the most recent 2.3.x at >> the time. >> >> Hopefully this clears up any concerns. When 2.5.0RC0 is put to a vote, fix >> versions will be tidy. It will also good for RC reviewers to check my work >> on the change log per usual. >> >>> On Mar 20, 2022, at 10:20 AM, Andrew Purtell <[email protected]> >> wrote: >>> >>> I have been setting both but don’t claim that is correct. >>> >>> This is partly my fault for pushing back 2.5.0 for about six months >> since cutting the branch. Partly this was waiting for always the next thing >> to squeeze in, and partly life and work obligations getting in the way. >>> >>> I am actually ready personally to release 2.5 now. I would like to pause >> commits to branch-2.5 and cut a release after test stabilization. However >> some tasks are not quite done. There is the SFT backport merge PR that I >> would like approvals on so I can merge it and there are the two issues >> opened for post log4j2 merge issues, the one with the shell logging >> zookeeper noise at startup, and the one for the test failures due to CNFE. >> These should be resolved. Then we can cut 2.5.0RC0. >>> >>> When cutting the RC I will clean up fix versions. I did this before at >> 2.4.0RC0. There was some discussion on dev@ at the time you can refer to >> in the archive. We have an audit tool for the purpose plus manual >> inspection of the git history when necessary. This is how I would adjust >> fix versions, according to consensus at the last time: >>> >>> 1. If in branch-2.5 only: fix version = 2.5.0 >>> >>> 2. If in branch-2.5 and branch-2: fix version = 2.5.0 >>> >>> 3. If in branch-2 only: fix version = 2.6.0. >>> >>> There is no need for anyone to do anything special until 2.5.0RC0. It >> would be helpful if you decide to do some work following the above rules to >> tidy fix versions, but not necessary, or you can continue to set both or >> either. >>> >>> After we release 2.5.0 at that point what to do with respect to fix >> versions for branch-2.5 should be clear. It is our current practice with >> patch versions. >>> >>> In any case when prepping 2.5.0RC0 I will need to perform the audit and >> make the necessary adjustments. >>> >>>> On Mar 20, 2022, at 5:59 AM, 张铎 <[email protected]> wrote: >>>> >>>> Recently I've seen we set both 2.5.0 and 2.6.0 as fix versions for some >>>> issues. >>>> >>>> But from my understanding, I always choose to only set 2.5.0 as fix >>>> versions if the patch has been committed to both branch-2 and >> branch-2.5. >>>> The assumption is that all issues resolved in 2.5.0 should also be >> included >>>> in 2.6.0. As before we cut branch-2.5, the patches committed to branch-2 >>>> will have fix version as 2.5.0, no 2.6.0, so even if we only commit some >>>> patches to branch-2.5 and not branch-2, it is impossible for us to find >>>> these out through the fix versions(which means it should not happen!)... >>>> >>>> So here I want to see what's the opinion of others in the community. Do >> you >>>> think we should set the fix versions with both 2.5.0 and 2.6.0, or we >>>> should only have 2.5.0, or it is not a big deal since duplication does >> not >>>> make things wrong? >>>> >>>> Thanks. >>
