mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #464] New Version Schema #7313
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#7313
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tiarebalbi on GitHub (Oct 3, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/464
Considering the new changes in how we release/deploy our change considering CI/CD, I would like just to raise this topic as I think it's getting to a point that just Major, Minor, and Path version are not enough.
New models such as {YEAR}.{MONTH}.{WEEK} are being used more often then we expect, this model is more friendly to the companies/project that are releasing, let's say, every Friday, one or more increments perversion.
Something similar to the https://github.com/mahmoud/calver.
I just think that this model could be part of the semver/semver
@klehelley commented on GitHub (Oct 3, 2018):
I personally do not think so. First remember that SemVer was conceived to help with evaluating API compatibility between two software component -- a provider and a consumer (be it a REST API, a data format, a programming language interfaces and classes) -- and the effort moving from one version to the other safely would require.
{YEAR}.{MONTH}.{WEEK} and other schemes based on build or release date do not tell much to the designer of the consumer, apart that 2018.10.41 is more recent than 2018.09.39 and what the date of release was. It tells nothing of the effort that user should expect when updating its dependency from one to the other, which is the main problem SemVer tries to solve.
Also your scheme makes it hard to maintain several incompatible versions in parallel (for example a "legacy" branch 1.y.z and a "current" branch 2.y.z). It may not be a problem in your case, and not all projects need that, but some do and SemVer can still be used with that kind of constraint.
Do note that SemVer does not try to solve every single problem related to version numbering, and that it leaves room for other numbering schemes. If the problem it tries to solve is not the one a given project has, or that it has another more important problem that it wants to focus on (simplicity of integration with CI/CD in your case), it is perfectly OK to choose a different versioning scheme.
Finally, using both SemVer and Continuous Delivery is actually a hard problem. It requires either specific tools to validate and detect the changes between each valid commit to automatically choose which number to increment, or it relies on developers identifying the kind of change they make in every commit to let the delivery pipeline know which number to increment.
I've actually been asked about which versioning scheme to use in the past for a project that wanted to use Continuous Deployment, for the artifacts that were deployed (not the API these artifacts exposed, but the artifacts themselves), and my advice back then was to directly use the commit id or the Jenkins build id (with a preference for the former), but definitely not SemVer since it brought nothing to them.
@tiarebalbi commented on GitHub (Oct 3, 2018):
Closing this issue as I agree with you that SemVer is a solving a specific type of problem and the CD part could be part of some other spec...