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.we...@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 <u...@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 <rcm...@gmail.com> wrote:
> >>
> >> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov <msoko...@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-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> > --
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Reply via email to