I think we have consensus here that we should set fix version to 2.5.0 only if the patch has been committed to both branch-2 and branch-2.5.
And I think the solution to cleanup the incorrect fix versions also works. Thanks Nick. And thanks all for chiming in. Andrew Purtell <[email protected]> 于2022年3月22日周二 01:36写道： > I think the sanest policy is — lowest released first —. So if released in > 2.4.11, then that’s all we need, for .0 versions. > > 2.5.0 changelog will be based on that of 2.4.11 or later. 2.6.0 changelog > will be based on 2.5.0 or later. It all rolls up. > > When committing to releasing code lines we also need a fix version for > each minor it will appear in. > > So for 3.0.0, this code line is already releasing alphas. You should > update fix versions to latest 3.0.0-alphaX when committing a change to > master branch. > > > > > > On Mar 21, 2022, at 10:30 AM, Nick Dimiduk <[email protected]> wrote: > > > > 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. > >>>> > >> >
