Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

Add semantic versioning to the project release flow #264

Open
dimabru opened this issue Nov 2, 2021 · 3 comments
Open

Add semantic versioning to the project release flow #264

dimabru opened this issue Nov 2, 2021 · 3 comments
Labels
enhancement New feature or request up for grabs Looking for a contributor to take this task WIP Working in progress (will be deployed soon)

Comments

@dimabru
Copy link
Contributor

dimabru commented Nov 2, 2021

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

@dimabru dimabru added the enhancement New feature or request label Nov 2, 2021
@eyarz eyarz removed the stale issue label Nov 12, 2021
@datreeio datreeio deleted a comment from github-actions bot Nov 12, 2021
@kevholmes
Copy link
Contributor

  1. 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
Copy link
Contributor Author

dimabru commented Nov 14, 2021

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 eyarz added the up for grabs Looking for a contributor to take this task label Nov 16, 2021
@noaabarki noaabarki added the WIP Working in progress (will be deployed soon) label Apr 18, 2022
@eyarz
Copy link
Member

eyarz commented Jun 22, 2022

@dimabru is this issue still relevant?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request up for grabs Looking for a contributor to take this task WIP Working in progress (will be deployed soon)
Projects
None yet
Development

No branches or pull requests

4 participants