Define release guidelines, and start publishing releases using semantic versioning

[Arvinderpal]

Currently, metal-3 sub-projects capbm and bmo do not publish releases.

We should adopt a releasing approach similar to that of CAPI and follow the well-known semantic versioning guidelines (see references below).

Besides this being a good practice, integration with the redesigned clusterctl will require that projects follow the above mentioned releasing strategy.

References:
https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/developer/releasing.md
https://semver.org/

[russellb]

For CAPBM, doing whatever makes it easiest to work with the rest of cluster-api makes sense to me. We should follow the versioning scheme recommended by cluster-api.

[Arvinderpal]

capi Makefile has various release commands, though I don't think they have ever been used. We can adapt those and also do something similar for baremetal-operator.

We'll need someone with the following permissions:

• Push access to the docker repo -- quay.io/metal3-io
• Tag push access to the GitHub repository
• GitHub Release creation access

I don't have any of those. @maelk can you cut a release or give me the appropriate permissions?

[maelk]

Yes, I should be able to do that, let's discuss it in the meeting today

[stbenjam]

/kind documentation

Should we have a standard release process defined in metal3-docs?

[maelk]

yes we should, I'll add that to our documentation work items

[dhellmann]

I'm going to close this in favor of the issue in the metal3-docs repo.