mirror of
https://github.com/semver/semver.git
synced 2026-07-11 09:22:32 -05:00
[GH-ISSUE #543] [PROPOSAL] : breaking change bit in the version number #1266
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1266
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 @anikethsaha on GitHub (Dec 24, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/543
Outline
as of v2 (not sure about v3 ), sematic versioning supports three types of versioning
I am proposing to have the 4th bit in the version number as breaking change bit.
Proposing Breaking change bit or flag (v0.0.0.X)
Here the 4th number will be either
0or1. which will specify whether the release contains any breaking change or not.Examples
Why
A release whether it's major or minor or patch may or may not contain breaking changes but there is no way to check or know that when doing a simple version bump. having this will be a kind of notifier to users.
A simple use-case of this will be dependencies management bots eg -
dependent-botorrenovateetc. I am pretty sure its kind of overwork or exhausted to feel when reviewing any PR by these bots as we need to manually look the changelog or sometimes compared commits when changelog is not present to know whether the release contains any breaking changes or not.having this proposal supported by the bots , now our bots can have an understanding of the content better. So even we can configure the bot to auto-merge the PR if the breaking change flag (v0.0.0.X) is set to
0I am not sure whether calling the number's position as a
bitis right, please correct me if requiredThanks
@jwdonahue commented on GitHub (Dec 24, 2019):
The standard already has breaking changes covered. You bump the major version and no minor or patch change should ever be released with a known breaking change.
For bots, take a look at VersionMeta and VersionSchema.
@anikethsaha commented on GitHub (Dec 24, 2019):
true, But there are cases when we don't have any breaking changes in the major release. My point is that having breaking changes with a release is too unpredictable. even patch release comes with breaking changes.
@ljharb commented on GitHub (Dec 24, 2019):
If there’s no breaking changes, why is it a major? That’s the sole purpose of a major version.
@anikethsaha commented on GitHub (Dec 24, 2019):
May be to land up a major feature. !!
@ljharb commented on GitHub (Dec 24, 2019):
That'd be a semver-minor, regardless of the desired sentimentality of the feature.
@anikethsaha commented on GitHub (Dec 24, 2019):
Okay .
What would you consider a release of migrating the codebase to typescript?
I would consider it as major but this won't break explicitly any API so I wouldn't consider this as breaking change.
Right ?
@sungam3r commented on GitHub (Dec 24, 2019):
Breaking for whom?
@anikethsaha commented on GitHub (Dec 24, 2019):
I didnt get this !!!
@sungam3r commented on GitHub (Dec 24, 2019):
OK. You have changed the internal mechanisms. Clients do not know anything about this and should not know.
@anikethsaha commented on GitHub (Dec 24, 2019):
Should not know about breaking changes ?
Why not ?
@sungam3r commented on GitHub (Dec 24, 2019):
Once again.
So there are no breaking changes for clients.
The fact is that the concept of breaking changes itself is not applicable to internal server changes.
And what is the use for clients from this? They are not interested. They do not work with the server implementation, but with its abstraction through the api boundary.
@sungam3r commented on GitHub (Dec 24, 2019):
By the way, if you are worried about marketing goals, you can simply version the server implementation and its api separately.
@ljharb commented on GitHub (Dec 24, 2019):
@anikethsaha changing from JS to TypeScript - or any other language - is utterly irrelevant. If the compiled/transpiled output behaves the same, then it's a patch. If it behaves differently (including its API surface, peer deps, etc), then it's the behavior change that determines the semver, not whatever flight of fancy you happen to author it in.
@anikethsaha commented on GitHub (Dec 24, 2019):
Ohh cool 👍
thanks @ljharb @sungam3r @jwdonahue for responding