Add semantic versioning to the project release flow

[dimabru]

Is your feature request related to a problem? Please describe.
We used to use svu in our project. Because of some technical difficulties we removed this dependency and the versioning is now hard-coded.
We'd like to reintroduce svu to our project (or any other recommended version management solution)

Describe the solution you'd like

1. Clean unused files from the ./scripts folder (deploy.sh for example is not used anymore)

2. Both deploy_release_candidate.sh and release.sh are using the same logic to determine the version. Use define_semver_number.sh script instead to avoid code duplication

3. Remove hard-coded MAJOR_VERSION and MINOR_VERSION variables and use svu logic to determine next release version

4. Versioning should work as follows:
   for x.x.x -> major.minor.patch

• Every feat! should bump major version
• Every feat should bump minor version
• Everything else should bump patch version
• Every commit to main should bump exactly one of the above
  for example:
  two feat commits should bump one minor version
  feat and fix commits should bump one minor version

Describe alternatives you've considered
svu is not mandatory for this solution. This is a suggested package to use but we're not set on it and are open to alternatives

[kevholmes]

4. Versioning should work as follows:
   for x.x.x -> major.minor.patch

• Every feat! should bump major version

1.0.0 -> 2.0.0

• Every feat should bump minor version

1.0.0 -> 1.1.0

• Everything else should bump patch version

1.0.0 -> 1.0.1

• Every commit to main should bump exactly one of the above
  for example:
  two feat commits should bump one minor version
  feat and fix commits should bump one minor version

This might be an issue?

Let's say we made an actions workflow that triggers only on push into main events.

This workflow would run some semantic version script that evaluates the final merged commit-msg and increments our semantic version based on some rules like does the commit-msg contain feat etc. We then apply that new version as a git tag to our commit in the main branch.

The issue I see here is that each PR merge into main is a single event that will trigger our action's workflow. So let's say we had two feat PRs waiting to be merged into main. I merge both into main in any order.

The workflow will run twice, once for each feat PR merge. Our semantic version would go from 1.0.0 to 1.1.0 then 1.2.0.

If we take that same scenario and also add a fix in there which should increment the patch version, we might see behavior like:

Start at 1.0.0

feat PR merged -> 1.1.0

fix PR merged -> 1.1.1

feat PR merged -> 1.2.0

---

Let's say we had those same three PRs to merge, but the order of the actions running is slightly different when we approve all three around the same time:

Start at 1.0.0

feat PR merged -> 1.1.0

feat PR merged -> 1.2.0

fix PR merged -> 1.2.1

---

If a number of PRs were merged together this is the behavior that svu running inside a GitHub Action triggered on push events to main would show us (from what I can tell). Is that what you're looking for?

[dimabru]

As of now, we don't really have versioning in our project. Meaning the backend does not support multiple cli versions and whenever we need to we deprecate old versions (though we try really hard not to).

The order of commits to main will in fact change the versioning of the cli but we're ok with it. We plan to work on specific branch-related commits in the future should we need to push bug fixes for specific releases, and when we get there we will add support for deployments from version branches (currently named release-x.x.x).

[eyarz]

@dimabru is this issue still relevant?