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