Feature: Workflow to update version.py _before_ publishing a release

[yardasol]

Background and motivation

There is currently no safeguard or process against publishing a release without changing the version inversion.py to indicate a full release.

Description of idea

There should be some process that either automates switching _version_extra in version.py from 'dev' to '0' before publishing a release, or enabled editing of the saltproc/version.py file once the release is published. Both would be nice.

We should also remove the "in-development" note from the release notes file for the current release before publishing.

Implementation details

Some ideas on how to do this:

• Make the next-minor-release.yml workflow trigger from closing a milestone, and add functionality to change version.py as well as publishing the current draft release. We will also document this in the Developer guide.
• Implement Feature: Branched release model #116 so we can update version.py as needed after publishing a release
• Add a workflow that makes a PR making the changes to version.py that must be merged before publishing the release

Useful resources:

• GitHub REST API References:
  • Publishing a release
  • Creating a reference (branch). Related stackoverflow post
• Webhook events:
  • Milestones
• Triggering workflows based on milestone events

Rough outline:

1. Get name of the milestone we closed
2. Merge the master branch into the branch with the same name as the milestone.
3. Find the release with the same name (tricky part)
   2a. Will need to do stuff w/ JSON matching most likely
4. Update version.py
5. Update the release notes file
6. Create a PR using the REST API
7. Merging this PR will publish the release.

Potential snags

We may need to implement these changes over multiple PRs. We also may need to cannibalize parts of next-release-minor.yml

[yardasol]

@munkm any thoughts?