[DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

["张铎(Duo Zhang)" <pa...@gmail.com>]

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.

Re: [DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

["张铎(Duo Zhang)" <pa...@gmail.com>]

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 <an...@gmail.com> 于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 <nd...@apache.org> 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 <
> andrew.purtell@gmail.com>
> >> 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 <nd...@apache.org>
> 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 <
> >> andrew.purtell@gmail.com>
> >>>> 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 <
> andrew.purtell@gmail.com
> >>>
> >>>> 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, 张铎 <pa...@gmail.com> 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.
> >>>>
> >>
>

Re: [DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

[Andrew Purtell <an...@gmail.com>]

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 <nd...@apache.org> 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 <an...@gmail.com>
>> 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 <nd...@apache.org> 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 <
>> andrew.purtell@gmail.com>
>>>> 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 <andrew.purtell@gmail.com
>>> 
>>>> 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, 张铎 <pa...@gmail.com> 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.
>>>> 
>> 

Re: [DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

[Nick Dimiduk <nd...@apache.org>]

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 <an...@gmail.com>
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 <nd...@apache.org> 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 <
> andrew.purtell@gmail.com>
> >> 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 <andrew.purtell@gmail.com
> >
> >> 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, 张铎 <pa...@gmail.com> 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.
> >>
>

Re: [DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

[Andrew Purtell <an...@gmail.com>]

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 <nd...@apache.org> 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 <an...@gmail.com>
>> 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 <an...@gmail.com>
>> 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, 张铎 <pa...@gmail.com> 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.
>> 

Re: [DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

[Nick Dimiduk <nd...@apache.org>]

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 <an...@gmail.com>
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 <an...@gmail.com>
> 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, 张铎 <pa...@gmail.com> 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.
>

Re: [DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

[Andrew Purtell <an...@gmail.com>]

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 <an...@gmail.com> 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, 张铎 <pa...@gmail.com> 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.

Re: [DISCUSS] On setting fix versions with both 2.5.0 and 2.6.0

[Andrew Purtell <an...@gmail.com>]

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, 张铎 <pa...@gmail.com> 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.