Change versioning strategy

[demisx]

We have run into an issue with our versioning. Using polkadot base version v0.9.29 and then subsequent with a -X ie v0.9.29-1 is great. I like it still, but it causes an issue for any npm packages reusing that version. (0.9.29 > 0.9.29-X).

Path Forward

1. Our version base will be our own. We will release v1.0.0 soon
2. We will move the polkadot version into the build information with the polkadot version: aka +polkadot0.9.29
3. npm versions should strip that portion of the version. So chain version v1.0.1+polkadot0.9.29 should generate npm matching package version v1.0.1 (if needed, it can use build information for other data).

Todo

• Alter the logic for updating the version for chain
• Update the ci logic for testing matching versions
• Update the npm logic for generating a version (dropping the build information)
• Update the Release page of the wiki with the new setup
• Release new version
• Create a new story to consider implementing semantic commits Consider using and requiring Conventional Commits #878

Original Options

So we have a few options (from easiest to hardest more or less):

1. Never use the base version, always use a -X. Be it -0 or -1, it would solve the issue for npm however would (as our current setup is) be against semver.
2. Stop using the polkadot version as our base. Likely this means our next release is 1.1.0 (to be able to back date 0.9.29 -> 1.0.0 and 0.9.29-2 -> 1.0.2). Releases that are not hotfixes are likely always minor releases so patches can be reserved for hotfixes?
3. Same as 2 except we use build version information to contain the polkadot version. Eg: 1.0.0+0.9.29 or perhaps 1.1.0+polkadot0.9.30
4. Use a different version for npm (such as 1), but don't change anything else.
5. Other (I do like https://calver.org options, but that doesn't quite match our situation like our spec and doc website deployments)

Side Effects:

• The new release asset naming must be compliant with https://github.com/LibertyDSNP/metadata-portal. Reach out to @johnmela and @rlaferla.