On 16. Jan 2020, at 16:19, Marshall Schor <[email protected]> wrote: > > Once an release is made (e.g. the 3.1.1 release, last Nov 8), should the > milestone be "closed", with the optional due-date set to the release date?
I think it would be convenient if we tracked target versions on GitHub in a similar fashion as on Jira. Contrary to Jira versions, an issue/PR on GitHub can only have a single target milestone. I.e. one cannot assign a v2.10.5 and v3.2.0 milestone. It would be possible to use GitHub "projects" for this purpose though! That is another tab. An issue can be part of multiple "projects". So far, I have use the milestone however. When a PR affects multiple versions (e.g. v2, and v3), then I'd put in the "earliest" version - i.e. prefer v2 over v3. So the PR would me merged into a v2 branch, get as its milestone the upcoming v2 release (e.g. 2.10.5). When it gets "merge up" into v3, that goes unreflected in the GitHub metadata so far. When a version would be released, I'd close the milestone and set the release date as the due date. Before the actual release, the due date might be set as a rough roadmap indicator. I guess I forgot to close the 3.1.1 milestone ;) Closed now. Cheers, -- Richard
