So for example, if I apply a patch to master, branch-2, branch-2.5, and branch-2.4, I should only set its fixFor version to 2.4.x and 2.5.0, because 2.6.0 is assumed by 2.5.0 and 3.0.0 is assumed by 2.6.0 ?
On Mon, Mar 21, 2022 at 3:59 PM Andrew Purtell <[email protected]> wrote: > 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. > >> >
