Introduce semantic versioning and releases

[bedeho]

As we Atlas is now becoming more of a framework than a specific product instance, introducing proper semantic versioning and releases will be needed for third party users to manage their use of the product properly and safely.

Scope:

• Versions
• Releases
• Changelog

[kdembler]

How do you think semantic releases help operators? It's not like Atlas will be an NPM package that you add to your dependencies and increase its version once in a while. For now, all operators will need to have a fork of Atlas where they apply their own changes and periodically pull from upstream. In that case, what do release help with in your opinion?

[bedeho]

So there are two distinct issues at play here

• Releases: by this I means giving identifiable names to distinct versions of the software that are production ready. This has the main benefit that it helps all stakeholders clearly distinguish different versions of the product for communication and coordination purposes. For example being able to refer to something as BitcoinCore 0.19 has a lot of utility not only to core development, but outsiders (exchanges, wallets providers, infra operators) and even sophisticated users. While commits are sort of like names, they are not really suitable for this, not only because they are not so human readable, but also because they are tied to history of a particular repo, not the codebase as a distinct artifact. They also don't have the benefits of explicit naming schema that have their own semantics (see next point). There is also the ability to use the release feature on Github to organize a neat history of such releases, which is quite nice. In general have releases, in this sense, is quite normal for all sorts of software (e.g. Wordpress, Windows, Talisman, BitcoinCore), not only libraries.
• Versioning, possibly semantic versioning: There are many ways to give names to such releases, and I am not wedded to semantic versioning, but it seems like a good idea to try to add some meaning to the names, so that operators can easily understand how important or big a change is, and what it may involve to start using a new version. We are free to add our own meaning to help with this. So for example really small changes, like adding a new signer or fixing some UI issue, or making something new disableable, this would have patch version changes, signaling to operators that using these involves no conflict or problems. while bigger changes, like updating API of Orion/QN, or changing encoding of some local storage thing so that migration is required, or format of configuration files is changed in non-backwards compatible ways, they could be major version changes. Also being able to make pre-relase versions could be useful.