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.
