feat: include semantic release in the publish workflow for incremental version tagging and release note generation

[csaw-nhs]

Description

Semantic release (semantic-release) is used for automatically tagging and creating GitHub releases with change logs from commit messages. It uses the SemVer convention and the Conventional Commits specification by describing the features, fixes, and breaking changes made in commit messages.

Context

Type of changes

• Refactoring (non-breaking change)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would change existing functionality)
• Bug fix (non-breaking change which fixes an issue)

Checklist

• I am familiar with the contributing guidelines
• I have followed the code style of the project
• I have added tests to cover my changes
• I have updated the documentation accordingly
• This PR is a result of pair or mob programming

---

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

• I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

[csaw-nhs]

We could protect the main branch with "require PR's" and use Git Apps to add a semantic PR plugin to make sure they contain a SemVer convention. However I don't believe that branch protection rules are copied over when a template is used, so we might need to think about adding something like commitlint to the pipeline (either pre-commit if we want to enforce the convention on all commits, or just at the PR merge stage)

Finally, I think we might need to think about our preferred branching strategy (or even if we want to go that far) and decide if we want to configure semantic-release to work with release, alpha, next branches, etc

[regularfry]

This is a very good-looking patch. I want us to understand a couple of things, though:

Is SemVer appropriate to enforce across the board?

My default stance here is that it's ok as a starting point if you haven't already got a useful version policy in place, but there can be better options depending on the thing that's being versioned. SemVer is particularly good where it's used on individual libraries consumed by other people who have a choice about the version they consume, and where releases to more than one lineage need to be made. If any of those things aren't true - you're versioning more than one thing, or an app, or it's only for self-consumption, or the consumers can't choose whether or not to upgrade, or you're only ever releasing the tip, its usefulness drops off dramatically and you're better served by something that carries information other than inter-version compatibility.

What does this do for repositories that don't publish release artefacts?

semantic-release seems to want you to be publishing release artefacts via a mechanism it recognises and can control. I'm not familiar with it to know how deep this rabbit-hole is (if at all), but this seems like a strong assumption. We will want to support not publishing anything as a github or npm release in some cases, and we will want to avoid publishing every version in others. What problems is this likely to cause? Can we head them off? Am I worrying about nothing?

[csaw-nhs]

@regularfry following our discussion I've removed the previous versioning mechanism from the workflows, and now the version is pulled from the tag created by the SemVer step