feat(dev): add release and versioning guidelines

[josecm]

This PR introduces the release and versioning guidelines. I present it as a draft for opening discussion on two main questions:

1. Should we have release candidates (e.g. 1.2.0-rc1) during the stabilization stage?
2. What CI automation could we add to support this process? Examples would be:

• Adding protections to avoid merging of PRs not related to bug fixes, documentation or testing during stabilization;
• Automatic deployment of more complete test batteries for release candidates;
• More ideas?

TODO:

• Add release log and annoucement guidelines.

[danielRep]

Small typos and format changes.
Overall, I agree with everything.

[danielRep]

This PR introduces the release and versioning guidelines. I present it as a draft for opening discussion on two main questions:

1. Should we have release candidates (e.g. 1.2.0-rc1) during the stabilization stage?

IMHO, this could be postponed as we feel necessary to add such concept on the versioning for testing reasons for example.

2. What CI automation could we add to support this process? Examples would be:

• Adding protections to avoid merging of PRs not related to bug fixes, documentation or testing during stabilization;
• Automatic deployment of more complete test batteries for release candidates;
• More ideas?

I agree with the first point. In the same idea, we could automatically bump the version at each bug fix, feature added, etc.

[josecm]

@danielRep I think I addressed most of the issues. Also, I've increase the column limit to 100.

This PR introduces the release and versioning guidelines. I present it as a draft for opening discussion on two main questions:

1. Should we have release candidates (e.g. 1.2.0-rc1) during the stabilization stage?

IMHO, this could be postponed as we feel necessary to add such concept on the versioning for testing reasons for example.

Agree.

2. What CI automation could we add to support this process? Examples would be:

• Adding protections to avoid merging of PRs not related to bug fixes, documentation or testing during stabilization;
• Automatic deployment of more complete test batteries for release candidates;
• More ideas?

I agree with the first point. In the same idea, we could automatically bump the version at each bug fix, feature added, etc.

Yes. But I don't see how we'd integrate this into GitHub without tagging RCs, nor how we'd automatically identify bugs vs docs vs feature PRs. We would need a PR tag system, at least.

[danielRep]

Small missing tweaks @josecm . Please rebase too.

[josecm]

Change release cadence to be fixed every 4 moths.

[josecm]

@danielRep @miguelafsilva5 Along with the proposed fixes, I also introduced the section on the "Release Announcement".

[danielRep]

Please solve the checker issues @josecm