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
