Ability to close milestone on release if there is one matching version

phly / keep-a-changelog

Tools for manipulating CHANGELOG.md files in Keep A Changelog format, including tagging and releasing.

https://phly.github.io/keep-a-changelog/

BSD 2-Clause "Simplified" License

182 stars 23 forks source link

Ability to close milestone on release if there is one matching version #59

Closed michalbundyra closed 4 years ago

michalbundyra commented 5 years ago

Feature Request

Q	A
New Feature	yes
BC Break	no

Summary

It would be nice to have a feature to close milestone automatically during the release.

Also, we can consider creating new milestones on bump:major/bump:minor/bump:bugfix.

weierophinney commented 4 years ago

I'm going back and forth on this one.

With the proposed workflow for Laminas, closing the workflow creates the release, and not the other way around. Additionally, only bump/bump:bugfix/bump:patch would ever be used to create new milestones, as the latest branch typically will use the new Unreleased section (see #75) up until we know exactly what the new release name will be; at that point, unreleased:promote would be used. As such, I see the following possibilities:

Do nothing; milestone management is completely up to the developer, and can be done via API calls or existing CLI tooling.
Add "milestone" commands (create, close). Developers will call these manually when they want to perform those actions.
Add a flag for creating a milestone to each of the bump commands and/or the unreleased:promote command.

(The last option could be done in conjunction with the one prior.)

What are your thoughts, @michalbundyra ?

michalbundyra commented 4 years ago

@weierophinney two last points sounds fine for me.

My original request was before we changed the workflow, as I've seen many times unclosed milestones, but tag and release. If we are going to close milestone to trigger release this is not going to be a problem anymore. I just think it would be nice to create new milestone once we bump changelog, so then we can assign issues to it.

weierophinney commented 4 years ago

I've begun work in https://github.com/phly/keep-a-changelog/tree/feature/milestones

The new milestone:* commands all work, at least with GitHub, but I need to write tests for the new commands, events, and listeners. From there, I'll work on invoking those commands from the bump* and unreleased:promote commands. My plan is to have mutually exclusive --create-milestone {name} and --create-milestone-from-new-version options (the latter would use the new version injected in the changelog as the milestone name), and, when present, invoke the milestone:create command on successful completion of the bump operation.

weierophinney commented 4 years ago

Available now in 2.6.0.