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