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. >
