Proposed release process for sidetree reference implementation

[tplooker]

The following PR is a proposed CI assisted release process for the sidetree reference implementation.

Note - This needs to be tested and the repository needs a NPM_TOKEN configured into the secrets of the repository so that github has the ability to publish a package to npm.

Refer to ./docs/release-process.md for the proposed outlined process.

[OR13]

@tplooker this looks good, when do you think it should be converted from draft? Are there additional changes you want to make?

[tplooker]

@tplooker this looks good, when do you think it should be converted from draft? Are there additional changes you want to make?

Happy to mark it out of draft if its generally supported as a go forward approach, I would like to test it prior to merging though

[gjgd]

@tplooker "skip ci" and "release commit" feel like tags rather than commit messages. Have you considered using git tags instead ?

For example:

• An untagged commit to master does not trigger any push to npm registry
• A commit tagged "v1.2.3-UNSTABLE" triggers the unstable workflow
• A commit tagged "v1.2.3-STABLE" triggers the stable workflow

[tplooker]

@gjgd the reason I like having something in the commit message for skipping CI is if a PR is made that say just amends the docs and I don't want another unstable release triggered on merge into master, amending the commit message when merging the PR is easy whereas using a tag would be more of a pain?

w.r.t release commit we can shift to using a release tag, however there still has to be a release commit that bumps the version, changelog and hence should have a consistent name so that someone reviewing the history of master can quickly see the release commits, so why not use this as the convention for triggering the release?

In your workflow, would the PR submitter not have to push a tag to the repo every time we want a new unstable release (i.e alongside their PR)? This just feels like an extra step that many developers would be liable to forget?

[OR13]

I can see the value in using the commit structure to drive the behavior of release, particularly in a world where you never release from a local setup.

[OR13]

@tplooker @csuwildcat @thehenrytsai @codeglobally who has the NPM access token necessary to complete this work, and what stops us from merging these workflow changes as is and letting the workflows fail until the appropriate party adds them to github secrets :)

[OR13]

@tplooker pending tweaks to docs, this will be merged.