-
Notifications
You must be signed in to change notification settings - Fork 357
Add semantic versioning to the project release flow #264
Comments
1.0.0 -> 2.0.0
1.0.0 -> 1.1.0
1.0.0 -> 1.0.1
This might be an issue? Let's say we made an actions workflow that triggers only on 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 The issue I see here is that each PR merge into The workflow will run twice, once for each If we take that same scenario and also add a Start at 1.0.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
If a number of PRs were merged together this is the behavior that |
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). |
@dimabru is this issue still relevant? |
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
Clean unused files from the ./scripts folder (deploy.sh for example is not used anymore)
Both
deploy_release_candidate.sh
andrelease.sh
are using the same logic to determine the version. Usedefine_semver_number.sh
script instead to avoid code duplicationRemove hard-coded
MAJOR_VERSION
andMINOR_VERSION
variables and use svu logic to determine next release versionVersioning should work as follows:
for x.x.x -> major.minor.patch
feat!
should bump major versionfeat
should bump minor versionfor example:
two
feat
commits should bump one minor versionfeat
andfix
commits should bump one minor versionDescribe 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
The text was updated successfully, but these errors were encountered: