Re: Label vs. Milestone for version management?

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

Re: Label vs. Milestone for version management?

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

Re: Label vs. Milestone for version management?

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

Re: Label vs. Milestone for version management?

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

Re: Label vs. Milestone for version management?

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

Re: Label vs. Milestone for version management?

On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov 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,

Re: Label vs. Milestone for version management?

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 wrote: > > Hi all. > > I once proposed using Milestone for version management in GitHub

Re: Label vs. Milestone for version management?

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

Re: Label vs. Milestone for version management?

On Thu, Aug 25, 2022 at 6:11 AM Michael Sokolov 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 >

Re: Label vs. Milestone for version management?

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

Re: Label vs. Milestone for version management?

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 for main branch.

Label vs. Milestone for version management?

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