Use semantic versioning to tag releases

[eddybrando]

Is your feature request related to a problem? Please describe.

This project doesn't tag its releases, so there is currently no way to get a quick idea about the magnitude of the changes over time.

---

Describe the solution you'd like

Use semantic versioning, as it's a widely adopted standard:

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 backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Automate release bumping and tagging with a project like standard-version, combined with a CI strategy.

---

Related to #1095

[delapuente]

@eddybrando what do you want to accomplish by versioning the web?

[eddybrando]

I would like to use semantic versioning as a form of keeping an easily comprehensible structure of changes and their impact on the project over time.

I can think of a couple of scenarios when this can come in handy:

Scenario A: Pinpointing a code change
Say there is a code change you want to pinpoint with git bisect and the only reference you have is that the versions of the website relevant to you are only those after the latest major visual redesign. You can then easily ignore all changes prior to the current major version.

Scenario B: Semantic first glance reading of git history to travel back to an specific point in time
Currently as one goes through the git history, one only has the SHAs and commit messages as indicators of the changes. One cannot easily distinguish the magnitude of the impact of those changes without reading and evaluating every change. By having semantic versioning, one can easily scan the minor or major tags when looking for more impactful changes. This comes in handy when trying to pinpoint a regression or wanting to travel back to a version of the website without a current feature or with a feature that doesn't exist any more.

In addition, this would serve as a basis to implement a changelog as proposed in #1095.

[delapuente]

Semantic versioning does not seem to match the kind of changes expected in qiskit.org since it is intended to be used with APIs where you clearly can tell if a change is improving, extending or breaking backwards-compatibility. For using semver to track the magnitude of changes in the website, we first need to clearly define what does it mean to bump the version numbers in terms of some consumer value, the UX, for instance.

Please notice that keeping a healthy and quickly understandable story is also a competent way of solving the scenarios you described before and I'd be more inclined to define a series of standard tags for commit messages like content, or redesign, or new-page that enable an efficient search through history., rather than trying to version the web artificially or adding a too much granular CHANGELOG.md

[eddybrando]

Very good points @delapuente.

I like the proposal about defining a standard set of commit messages, as well. To that point, I would like to suggest something like Conventional Commits and maybe go with the Angular conventions or use them as a starting point.

[eddybrando]

The conclusion reached is that tagging releases or versioning this project doesn't really bring much value, at least as of now.