Mailing List Archive

For now, please use Label "fix-version:x.x.x" for version management as
written in
https://github.com/apache/lucene/blob/main/dev-docs/github-issues-howto.md.

In other words,

1. Use
fix-version:10.0
<https://github.com/apache/lucene/issues?q=label%3Afix-version%3A10.0+> for
main branch.
fix-version:9.4
<https://github.com/apache/lucene/issues?q=label%3Afix-version%3A9.4> for
9.x branch.

2. Do not use Milestone.
I removed Milestone 9.4.0. Sorry, we need a clear convention and
instructions about it. Milestone is fine with me, but we should avoid any
confusion unless we gain consensus on introducing it.

Feel free to push it forward if you would like, please.

Tomoko


2022?8?25?(?) 16:47 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> Hi all.
>
> I once proposed using Milestone for version management in GitHub before
> the issue migration.
> The proposal did not gain any support, so I thought we concluded that we
> use "fix-version" Label for issue/PR version management.
>
> But it looks like there are suggestions to use Milestone.
> What should we do?
>
> Tomoko
>

The milestone looks appealing since it is prominent and relatively easy to
use. The only drawback I have heard is that it is single valued. It still
seems we could use it to document the first version in which something is
released, although it wouldn't be possible to record other releases into
which a fix it feature is back ported.

I'm not entirely sure how we use this released in / fixed in information. I
understand users would like to be able to answer the question did release
x.y include this change. Did we also use it for release management? Like
looking for blockers to release some version? I think the former needs all
the versions and we could not support, but the latter only needs a single
version?

On Thu, Aug 25, 2022, 3:50 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Hi all.
>
> I once proposed using Milestone for version management in GitHub before
> the issue migration.
> The proposal did not gain any support, so I thought we concluded that we
> use "fix-version" Label for issue/PR version management.
>
> But it looks like there are suggestions to use Milestone.
> What should we do?
>
> Tomoko
>

On Thu, Aug 25, 2022 at 6:11 AM Michael Sokolov <msokolov@gmail.com> wrote:
>
> The milestone looks appealing since it is prominent and relatively easy to use. The only drawback I have heard is that it is single valued. It still seems we could use it to document the first version in which something is released, although it wouldn't be possible to record other releases into which a fix it feature is back ported.

The fix-version stuff seems like a JIRA relic to me. there are at
least two other places to get the information. If someone wants to
know this, they can see all the commits to the branches, can check
CHANGES.txt, etc?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

I agree; I've always used CHANGES for a quick historical view. What
about the release manager use case? I haven't done a release, but I
think we generally want to know if people are targeting changes for an
upcoming release, especially if they are blockers. We could just use
email to find out about these, but I think it's better if we can look
them up in the issue db.

On Thu, Aug 25, 2022 at 9:40 AM Robert Muir <rcmuir@gmail.com> wrote:
>
> On Thu, Aug 25, 2022 at 6:11 AM Michael Sokolov <msokolov@gmail.com> wrote:
> >
> > The milestone looks appealing since it is prominent and relatively easy to use. The only drawback I have heard is that it is single valued. It still seems we could use it to document the first version in which something is released, although it wouldn't be possible to record other releases into which a fix it feature is back ported.
>
> The fix-version stuff seems like a JIRA relic to me. there are at
> least two other places to get the information. If someone wants to
> know this, they can see all the commits to the branches, can check
> CHANGES.txt, etc?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Tomoko - sorry to re-raise this when we thought it had been settled.
Having never really used github issues, I don't think I fully
understood the arguments there.

On Thu, Aug 25, 2022 at 3:50 AM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Hi all.
>
> I once proposed using Milestone for version management in GitHub before the issue migration.
> The proposal did not gain any support, so I thought we concluded that we use "fix-version" Label for issue/PR version management.
>
> But it looks like there are suggestions to use Milestone.
> What should we do?
>
> Tomoko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov <msokolov@gmail.com> wrote:
>
> I agree; I've always used CHANGES for a quick historical view. What
> about the release manager use case? I haven't done a release, but I
> think we generally want to know if people are targeting changes for an
> upcoming release, especially if they are blockers. We could just use
> email to find out about these, but I think it's better if we can look
> them up in the issue db.

Mark them as priority blocker with a tag? that's all you could do with
JIRA, too.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

So the Solr Operator has been using Github Issues for a few releases now,
and the Milestone feature has worked really well for a blockers list.

I agree that it should not be the canonical list of things that were
included in that release (although it will likely be very close), but it is
very good for easily seeing what PRs/Issues are still open for a particular
version.
You can also see the milestone in the Issues & PR list, so it's easy to see
what version the Issues/PRs are targeted for at a quick glance.

- Houston

On Thu, Aug 25, 2022 at 10:12 AM Robert Muir <rcmuir@gmail.com> wrote:

> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov <msokolov@gmail.com>
> wrote:
> >
> > I agree; I've always used CHANGES for a quick historical view. What
> > about the release manager use case? I haven't done a release, but I
> > think we generally want to know if people are targeting changes for an
> > upcoming release, especially if they are blockers. We could just use
> > email to find out about these, but I think it's better if we can look
> > them up in the issue db.
>
> Mark them as priority blocker with a tag? that's all you could do with
> JIRA, too.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Hi,

In addition, once you have done a release, you can close the milestone
with the date of release and this would mark all those issues as
"delivered". So quick filters won't show them anymore. And for the RM it
is great to get a list of issues form the Milestones page. If you also
use the "release" feature in github it will create nice lists with date
of relaese, all fixed issues,... (but we have changes.txt and we don't
do releases with Github so it won't be useful, I just mention this).

I use that in forbiddenapis since long time (also for the pull
requests). But I also create my own markdown changes list there (because
it looks nicer and you can give more informationlike adding credits).

Uwe

Am 25.08.2022 um 17:05 schrieb Houston Putman:
> So the Solr Operator has been using Github Issues for a few releases
> now, and the Milestone feature has worked really well for a blockers
> list.
>
> I agree that it should not be the canonical list of things that were
> included in that release (although it will likely be very close), but
> it is very good for easily seeing what PRs/Issues are still open for a
> particular version.
> You can also see the milestone in the Issues & PR list, so it's easy
> to see what version the Issues/PRs are targeted for at a quick glance.
>
> - Houston
>
> On Thu, Aug 25, 2022 at 10:12 AM Robert Muir <rcmuir@gmail.com> wrote:
>
> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov
> <msokolov@gmail.com> wrote:
> >
> > I agree; I've always used CHANGES for a quick historical view. What
> > about the release manager use case? I haven't done a release, but I
> > think we generally want to know if people are targeting changes
> for an
> > upcoming release, especially if they are blockers. We could just use
> > email to find out about these, but I think it's better if we can
> look
> > them up in the issue db.
>
> Mark them as priority blocker with a tag? that's all you could do with
> JIRA, too.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:uwe@thetaphi.de

About the milestones being single-valued - we already have this
single-value notion in changes.txt, don't we? We add a note about the
issue to the "last" branch an issue was backported to. I agree
sometimes it could be more complicated (vide openjdk, where issues are
backported selectively to a few branches or fixed just on a historical
branch) but in Lucene things seem to follow a simpler, single-value
"milestone+later branches" model.

Dawid

On Thu, Aug 25, 2022 at 6:40 PM Uwe Schindler <uwe@thetaphi.de> wrote:
>
> Hi,
>
> In addition, once you have done a release, you can close the milestone with the date of release and this would mark all those issues as "delivered". So quick filters won't show them anymore. And for the RM it is great to get a list of issues form the Milestones page. If you also use the "release" feature in github it will create nice lists with date of relaese, all fixed issues,... (but we have changes.txt and we don't do releases with Github so it won't be useful, I just mention this).
>
> I use that in forbiddenapis since long time (also for the pull requests). But I also create my own markdown changes list there (because it looks nicer and you can give more informationlike adding credits).
>
> Uwe
>
> Am 25.08.2022 um 17:05 schrieb Houston Putman:
>
> So the Solr Operator has been using Github Issues for a few releases now, and the Milestone feature has worked really well for a blockers list.
>
> I agree that it should not be the canonical list of things that were included in that release (although it will likely be very close), but it is very good for easily seeing what PRs/Issues are still open for a particular version.
> You can also see the milestone in the Issues & PR list, so it's easy to see what version the Issues/PRs are targeted for at a quick glance.
>
> - Houston
>
> On Thu, Aug 25, 2022 at 10:12 AM Robert Muir <rcmuir@gmail.com> wrote:
>>
>> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov <msokolov@gmail.com> wrote:
>> >
>> > I agree; I've always used CHANGES for a quick historical view. What
>> > about the release manager use case? I haven't done a release, but I
>> > think we generally want to know if people are targeting changes for an
>> > upcoming release, especially if they are blockers. We could just use
>> > email to find out about these, but I think it's better if we can look
>> > them up in the issue db.
>>
>> Mark them as priority blocker with a tag? that's all you could do with
>> JIRA, too.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
> --
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Hi,
it looks like many people favor Milestone over Label? Then I would like to
bring my proposal utilizing Milestone for version management up again.

A draft plan in my mind:
- A Milestone represents a release. E.g. Milestone 9.4.0 includes all
changes in version 9.4.0.
- Associate issues/PRs to a Milestone where the changes should be delivered.
- Use Milestone for release planning. All issues that are associated with a
Milestone must be resolved before the release.
- If there are unresolved issues in a Milestone, they are blockers for
the release.

If this looks fine to you, I will do all the necessary things.
- Create a Milestone for 9.4.0.
- Associate issues/PRs that are labeled "fix-version:9.4" with Milestone
9.4.0.
- Rename all "fix-version:x.x.x" label to "legacy-jira-fix-verison:x.x.x"
to avoid possible confusion.
- Rewrite documentation about release planning.

I will wait for a while for further comments and suggestions, then proceed
with it next week.

Tomoko


2022?8?26?(?) 6:50 Dawid Weiss <dawid.weiss@gmail.com>:

> About the milestones being single-valued - we already have this
> single-value notion in changes.txt, don't we? We add a note about the
> issue to the "last" branch an issue was backported to. I agree
> sometimes it could be more complicated (vide openjdk, where issues are
> backported selectively to a few branches or fixed just on a historical
> branch) but in Lucene things seem to follow a simpler, single-value
> "milestone+later branches" model.
>
> Dawid
>
> On Thu, Aug 25, 2022 at 6:40 PM Uwe Schindler <uwe@thetaphi.de> wrote:
> >
> > Hi,
> >
> > In addition, once you have done a release, you can close the milestone
> with the date of release and this would mark all those issues as
> "delivered". So quick filters won't show them anymore. And for the RM it is
> great to get a list of issues form the Milestones page. If you also use the
> "release" feature in github it will create nice lists with date of relaese,
> all fixed issues,... (but we have changes.txt and we don't do releases with
> Github so it won't be useful, I just mention this).
> >
> > I use that in forbiddenapis since long time (also for the pull
> requests). But I also create my own markdown changes list there (because it
> looks nicer and you can give more informationlike adding credits).
> >
> > Uwe
> >
> > Am 25.08.2022 um 17:05 schrieb Houston Putman:
> >
> > So the Solr Operator has been using Github Issues for a few releases
> now, and the Milestone feature has worked really well for a blockers list.
> >
> > I agree that it should not be the canonical list of things that were
> included in that release (although it will likely be very close), but it is
> very good for easily seeing what PRs/Issues are still open for a particular
> version.
> > You can also see the milestone in the Issues & PR list, so it's easy to
> see what version the Issues/PRs are targeted for at a quick glance.
> >
> > - Houston
> >
> > On Thu, Aug 25, 2022 at 10:12 AM Robert Muir <rcmuir@gmail.com> wrote:
> >>
> >> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov <msokolov@gmail.com>
> wrote:
> >> >
> >> > I agree; I've always used CHANGES for a quick historical view. What
> >> > about the release manager use case? I haven't done a release, but I
> >> > think we generally want to know if people are targeting changes for an
> >> > upcoming release, especially if they are blockers. We could just use
> >> > email to find out about these, but I think it's better if we can look
> >> > them up in the issue db.
> >>
> >> Mark them as priority blocker with a tag? that's all you could do with
> >> JIRA, too.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> > --
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: uwe@thetaphi.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

I opened a PR to propose Milestone for release planning.
https://github.com/apache/lucene/pull/11723

Version management is one of the most important things for an
issue-tracking system. Is this clear to everyone?

```
## Milestones

We use Milestones for release planning.

A milestone represents a release. All issues/PRs associated with a
milestone must be resolved before the release, which means unresolved
issues/PRs in a milestone are blockers for the release.

Release managers should consider how to address blockers. Some may be
resolved by developers, and others may be postponed to future releases.

Once the release is done, the Milestone should be closed then a new
Milestone for the next release should be created.
```


Tomoko


2022?8?26?(?) 19:03 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> Hi,
> it looks like many people favor Milestone over Label? Then I would like to
> bring my proposal utilizing Milestone for version management up again.
>
> A draft plan in my mind:
> - A Milestone represents a release. E.g. Milestone 9.4.0 includes all
> changes in version 9.4.0.
> - Associate issues/PRs to a Milestone where the changes should be
> delivered.
> - Use Milestone for release planning. All issues that are associated with
> a Milestone must be resolved before the release.
> - If there are unresolved issues in a Milestone, they are blockers for
> the release.
>
> If this looks fine to you, I will do all the necessary things.
> - Create a Milestone for 9.4.0.
> - Associate issues/PRs that are labeled "fix-version:9.4" with Milestone
> 9.4.0.
> - Rename all "fix-version:x.x.x" label to "legacy-jira-fix-verison:x.x.x"
> to avoid possible confusion.
> - Rewrite documentation about release planning.
>
> I will wait for a while for further comments and suggestions, then proceed
> with it next week.
>
> Tomoko
>
>
> 2022?8?26?(?) 6:50 Dawid Weiss <dawid.weiss@gmail.com>:
>
>> About the milestones being single-valued - we already have this
>> single-value notion in changes.txt, don't we? We add a note about the
>> issue to the "last" branch an issue was backported to. I agree
>> sometimes it could be more complicated (vide openjdk, where issues are
>> backported selectively to a few branches or fixed just on a historical
>> branch) but in Lucene things seem to follow a simpler, single-value
>> "milestone+later branches" model.
>>
>> Dawid
>>
>> On Thu, Aug 25, 2022 at 6:40 PM Uwe Schindler <uwe@thetaphi.de> wrote:
>> >
>> > Hi,
>> >
>> > In addition, once you have done a release, you can close the milestone
>> with the date of release and this would mark all those issues as
>> "delivered". So quick filters won't show them anymore. And for the RM it is
>> great to get a list of issues form the Milestones page. If you also use the
>> "release" feature in github it will create nice lists with date of relaese,
>> all fixed issues,... (but we have changes.txt and we don't do releases with
>> Github so it won't be useful, I just mention this).
>> >
>> > I use that in forbiddenapis since long time (also for the pull
>> requests). But I also create my own markdown changes list there (because it
>> looks nicer and you can give more informationlike adding credits).
>> >
>> > Uwe
>> >
>> > Am 25.08.2022 um 17:05 schrieb Houston Putman:
>> >
>> > So the Solr Operator has been using Github Issues for a few releases
>> now, and the Milestone feature has worked really well for a blockers list.
>> >
>> > I agree that it should not be the canonical list of things that were
>> included in that release (although it will likely be very close), but it is
>> very good for easily seeing what PRs/Issues are still open for a particular
>> version.
>> > You can also see the milestone in the Issues & PR list, so it's easy to
>> see what version the Issues/PRs are targeted for at a quick glance.
>> >
>> > - Houston
>> >
>> > On Thu, Aug 25, 2022 at 10:12 AM Robert Muir <rcmuir@gmail.com> wrote:
>> >>
>> >> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov <msokolov@gmail.com>
>> wrote:
>> >> >
>> >> > I agree; I've always used CHANGES for a quick historical view. What
>> >> > about the release manager use case? I haven't done a release, but I
>> >> > think we generally want to know if people are targeting changes for
>> an
>> >> > upcoming release, especially if they are blockers. We could just use
>> >> > email to find out about these, but I think it's better if we can look
>> >> > them up in the issue db.
>> >>
>> >> Mark them as priority blocker with a tag? that's all you could do with
>> >> JIRA, too.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> > --
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>