Streamline release process

[DaniBodor]

The release process currently works as described in the documentation, but it is somewhat tedious and requires many steps/clicks, etc.

We discussed streamlining this process as follows:

• create a dev or development branch, which will be the standard working branch for creating new features, etc
  • this will not be the formal "GitHub default branch", as that would have some unwanted side-effects.
  • this means that PRs will by default merge into main, which needs to be manually changed to dev (reviewers, be aware!)
  • hotfixes, improved documentation of existing code, etc can be merged directly into main.
• create a release action, which goes through all the steps for making a release
  • this probably involves one generic action for most of the steps, and three separate manually triggered trigger-actions for major, minor, patch updates.
  • alternatively, it could be triggered whenever a merge to main was made (and a python file was changed/added), but it's unclear how the semantic version level would be detected.
  • one option would be to require (via a separate action) a bumpversion change to be done in any PR that wants to merge to main.
  • auto-generated release notes can be manually edited after publishing
  • if dev is merged into main, we'd want main to be automatically merged back into dev.
  • Not clear what would happen if a hotfix is merged into main that bypasses dev.

We will probably heavily rely on chatgpt to create this action.

@psomhorst , anything to add to this?

[psomhorst]

• gitflow uses the branch name develop instead of dev or development
• it is possible to trigger an action when a PR is closed and merged to main; if the PR did not come from develop (i.e. a hotfix) it should be merged to develop. https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-pull_request-workflow-when-a-pull-request-merges

[DaniBodor]

Update on this issue:

I have an untested draft of the action in e8c4291. The way it is set up for now is that it can be manually triggered (on Actions tab) using a keyword and fails if that keyword is not patch, minor, or major. I genuinely don't know what to expect of how to give this input, as I have never created a manually triggered action with an input before.

However, I am fairly certain that ultimately this action will fail on the step of pushing onto main, as it is branch protected. I haven't found (yet) how to bypass branch protection by a GitHub action. Something like this may work, but seems complex to set up. Alternatively, rather than a manual trigger on the actions tab, an automatic trigger could be made that recognizes a branch or PR name (e.g. starting with a given keyword/-phrase like release patch) being merged into main? The manual step would then become to merge such a PR into main. However, bumpversion could still not be run from inside the action without branch protection override, so this is also still not ideal.

On a side note: I am also looking into how these can be triggered from another branch than the default one (which is why it's still untested). I believe GitHub CLI needs to be installed for this, as mentioned here.