mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #35] Howto: 1.x needs breaking update but 2.x already exist? #7001
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#7001
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 @ITemplate on GitHub (Jun 19, 2012).
Original GitHub issue: https://github.com/semver/semver/issues/35
Hi.
Just looking for some best practice here. Suppose you have an application where you have 2 incompatible "branches": 1.x and 2.x. Now the situation arises that a breaking change needs to be implemented to 1.x. This new change is not compatible with 2.x and should not be included in that branch. In other words, this new breaking change is only for 1.x.
The change does not change the application name or intent. What should the new version be?
Werner
@robsimmons commented on GitHub (Jun 19, 2012):
Think it's gotta be 3.x, right? That's a bit ugly, but if you're maintaing two incompatible branches and making breaking changes to both of them, it might make sense for one or the other to become a differently-named project, I'd think.
@thomashw commented on GitHub (Jun 19, 2012):
With your version numbers in the form X.Y.Z, increase the Z of your 1.Y.Z branch to implement the breaking change (I'm assuming this "breaking change" is some sort of bug fix - see 6 of the specification).
If it is not a bug fix and new, backwards compatible functionality is being introduced, increase the Y of your 1.Y.Z branch (see 7 of the specification).
If the change isn't backwards compatible, then I agree with robsimmons that it seems the project is going in two different directions.
@robsimmons commented on GitHub (Jun 19, 2012):
I read "breaking change" as "backwards incompatible changes are introduced to the public API," but if breaking change is read in some other way thomashw is, of course, absolutely correct. I've seen numbers integrated into project names formally or informally before, so you could maintain semantic versioning talking about "FooBar 2, version 1.2.4" versus "FooBar 2, version 9.4.1rc1" versus "FooBar, version 3.2.1."
@ITemplate commented on GitHub (Jun 21, 2012):
Indeed I mean incompatibe breaking changes. Which would bump 1.x to 2.x. But already exists - hence my dilemma. I agree with both robsimmons and thomashw that conceptually this is another application. But just wanted to be sure that there wasn't a better practice :)
Thanks.
Werner
@robsimmons commented on GitHub (Jun 21, 2012):
(I guess this issue is basically closed, then, if someone wants to close it.)