feat: allowing alpha.sh to publish custom npm tags

[fboucquez]

example: bash alpha.sh my-experimental-tag

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[Jaguar0625]

why do we need this? i think we generally want to get away from using alpha tags? @0x6861746366574?

[fboucquez]

The 'alpha' tag is for ready-to-be-released artifacts, just that we are not ready to release yet. People/dev can still install them if they want to try a feature before a full release.

[0x6861746366574]

why do we need this? i think we generally want to get away from using alpha tags? @0x6861746366574?

Yes, agreed, we do not want to use alpha/beta tagging - we want to keep consistency with our versioning across the organization.

The general flow should be:

• Development on a local branch > push to feature or task branch for testing and automated checks (Travis, Coveralls, LGTM, Sonarcloud).
• Once ready, submit a pull request to /dev and wait for a review from a maintainer.
• Once the pull request has been accepted into /dev ("accepted" status), it's ready for inclusion in a release candidate.
• Once a release candidate has been prepared (ideally we'd follow the release schedule of catapult-client), submit a pull request to /main.
• Wait for review from the maintainer or release coordinator.
• Once submitted, build, tag, prepare detailed version notes (along with a detailed list of what changed, and why) and Bob's your uncle!

Nothing is stopping people from trying features in a feature branch, or the /dev branch.