Include workflow for automatic CHANGELOG and version bumps

[howard-e]

Added workflows/version-changelog-update.yml to automatically bump the app's version and update a CHANGELOG.md, when the releases branch is updated.

The workflow makes use of TriPSs/conventional-changelog-action which automates the version bumping, tagging and CHANGELOG.md generation needs.

This also updates relevant docs related to this new release practice.

Note: This assumes a development exists (and is the default branch) and a releases branch exists.

[jugglinmike]

Thanks for taking the lead on this, @howard-e!

[jugglinmike]

It's a little unorthodox to restrict folks' branch names (especially in the ideal case that the pull requests are coming from external forks), but if we want to do this, I think a little more guidance will be necessary.

[howard-e]

... to restrict folks' branch names ...

Correct and definitely not the intention of the line. Reading it back now, I also see how it can be interpreted as such. I'll simplify it to "Create an appropriately named branch"

Done in 610dc55

[jugglinmike]

How about we require the tests to pass? I believe the syntax would be:

 jobs:
+  tests:
+    uses: ./.github/workflows/runtest.yml
   version-changelog-update:
+    needs: tests
     permissions:
       contents: write

Along with a corresponding addition of workflow_call to runtest.yml.

[howard-e]

I like the thought, although I would have liked to hope the tests were confirmed as passing to have even got there? Seems doing something like the following in runtest.yml to avoid doubling up on that run should be done:

# runtest.yml

on:
  push:
    branches-ignore:
      - releases # version-changelog-update which triggers on a push to releases will still trigger this workflow through `workflow_call`
  pull_request:
  workflow_call:

Seems useful as well on #912, for an automated deployment.

[jugglinmike]

...or we might disable pushing to the branch and instead only merge via GitHub pull request. That would likewise allow us to require that the tests pass, and it would also make the release process more visible.

[howard-e]

...or we might disable pushing to the branch and instead only merge via GitHub pull request. That would likewise allow us to require that the tests pass, and it would also make the release process more visible.

That would be fine with me! I think that also addresses my thought in the previous thread:

although I would have liked to hope the tests were confirmed as passing to have even got there

[alflennik]

Great work, it is exciting to see our workflow entering the next phase, and having seen all the manual work needed to track our releases, this will be a huge efficiency boost.

@howard-e I know I'm the second reviewer but can you merge this? There are other reviewers assigned, and it seems like we might need to create a new development branch so I wanted to leave that to you. Also when you do merge it, would you mind sending a notification to the team so they know to update their practices?