feat: Adopt conventional commits and correct semantic versioning

[fastlorenzo]

Problem statement
It' be great to have a clear view in the changelog on what are bug fixes/patches, new functionalities or breaking changes, and have it reflected in versions.
One good option could be to use https://www.conventionalcommits.org/

Expected behavior

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

https://semver.org/

Mock
N/A

Additional context
N/A

[ab-smith]

Thank you @fastlorenzo

Interesting discussion indeed. We had it at multiple occasions internally and here are the highlights:

• we'll try to go PR squash as much as possible from now on so the semantics of the commits won't matter much, but the title of the PR will, for which we can have an equivalent convention. This is specially relevant given that the changelog is generated and based on the PR titles.
• the semver convention is important but relevant for the API, not the app versioning. Once the API and its swagger graduate from the experimental phase, it will definitely follow that.

Warm regards

[fastlorenzo]

@ab-smith I totally agree on the squash PR, this is so much easier to read. What I meant with the conventional commits was for the main branch, so for those commits when merged.
If done properly, you could also make use of something like https://github.com/googleapis/release-please to generate changelog and bump versions accordingly.

Agreed for the semver convention for API, but it'd be great to know from the version as well if something was massively changed or removed from the UI (e.g. #1204 was a patch version, but had implications on the UI so should have been at least considered minor if not major as you removed a UI feature).
If done well, this helps auto-upgrade of environments (e.g. we can rely on auto-patching for PATCH version, knowing nothing would break as it's just a patch)

I understand though that you're in a heavy dev phase, so doing so might be difficult for the moment as well.

My 2 cents 😉

[ab-smith]

Oh don't get me wrong, I do appreciate your inputs and you taking the time to word them :)

For the the #1204 it was a regression due to a refactoring of the component, to space the requirement rendering a bit better, so I don't believe we can take it as an example for a massive/breaking change.

I do get the sentiment though on the importance of mentioning the UI changes on the release notes in a better way and that will be the immediate takeaway, in addition to the linear approach with squashes. The release-please is definitely something worth exploring to say the least to compare it to the native release notes generator of GitHub.

This is discussion is a good food for thoughts, so thanks again and I'll keep it open to circle back to it in the upcoming weeks.

And yes, we have a few big features coming up, but it's never too late or secondary to do better on our practices and communication 🤗