mirror of
https://github.com/semver/semver.git
synced 2026-03-11 00:12:22 -05:00
Supporting multiple version & Major Version #296
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#296
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 @JonathanMagnan on GitHub (Sep 19, 2017).
On one of my project, someone asked me to follow Semantic Versioning, here is the discussion: https://github.com/zzzprojects/html-agility-pack/issues/74
However, I have some concern about MAJOR version since it seems that doesn't fit with all kind of project.
I would like to know how you will manage when multiple version is supported at the same time.
Let say the project has two version:
Even if the v2.x is out, I must still support the v1.x since not everyone can move to the v2.x since there is several breaking change.
By looking at the Semantic Versioning:
So how do you propose to handle breaking change when you support two version at the same time?
@hofmand commented on GitHub (Sep 19, 2017):
You want to introduce breaking changes so your customers won't have to deal
with breaking changes. That's an interesting paradox!
On Sep 19, 2017 3:45 PM, "Jonathan Magnan" notifications@github.com wrote:
@JonathanMagnan commented on GitHub (Sep 20, 2017):
Thank you @jeme for your opinion.
I understand your point.
Project Name
You cannot change so easily product name. There are thousands of links that point to a project URL, or NuGet Package (https://www.nuget.org/packages/HtmlAgilityPack/).
Modifying the product name cannot be done so easily as you build your reputation on the project name and all external linking is done on it.
AspNetandAspNetCoreare two very different product which both are ongoing development. I don't think this example is the best fit for my scenario.Almost every library
jQuery,Bootstrap,Angular,Windows,Apple IOs, etc. doesn't change the project name but increment the major version.Modyfing product name is a simple
NOBreaking Changes
As you said, what's a breaking change can be discutable.
Should it be introduced or not is also another question!
But the point is it seems that this Semantic Versioning doesn't handle this basic scenario.
Major Version
The Semantic Versioning work very great for a big library that is under development for years. By example, Bootstrap who is under ALPHA/BETA since 2014.
When they release a major version, their API is already well tested by millions of developers around the world. So they likely not do any
Breaking Changesfor this version or previous version.However, for rapid development product, the API may be broke a few times since we don't have the same user base, developer team, budget, etc.
We don't want to stay in
BETAfor years either since we need to push forward to stay motivated. If we keep incrementing the MAJOR version every time there is an API break, we make even users lose track of what's a MAJOR version since they are used to see this version incremented when there is a whole library revamp or a very big change.So far, it seems the definition of a MAJOR version in this Semantic Versioning go against how 99,9% of library manage it.
Best Regards,
Jonathan
@FichteFoll commented on GitHub (Sep 20, 2017):
From having worked with semver without any issues so far and considering its adoption, especially on npm, I wonder where this 99.9% figure is coming from.
If you don't agree with the premise of following the semver spec, then don't do it. This decision is entirely on you. Either you promise your users/customers that they have a numbering system they can systematically rely on by following semver, or use a custom versioning system based on "feels". However, do not do the latter and declare you're following semver.
FireFox and Chrome increase their major version regularly every X weeks, although they use a slightly different versioning system.
Imo, Angular did a huge mistake with declaring its successor as "Angular 2", just as @jeme explained. It's basically an entirely different product but uses the same name.
Windows is kind of weird, but they do have lots of backwards compatibility in their API because software from previous OSes is expected to continue working on the latest. Also, since Windows 10 is supposedly their final OS, it can probably be considered a product on its own with having its own version numbers. Either way, Windows isn't following semver either.
@JonathanMagnan commented on GitHub (Sep 20, 2017):
Hello @FichteFoll ,
I know the decision is on my side, but I just want to understand this semantic better to make sure I take the right decision for this project or any other situation that may happen in the future.
You are right, perhaps the 99,9% is wrong and exaggerated.
Again you are right,
FireFoxandChromeincrease they major version regularly, but they also stop to support the previous version and keep moving forward.I believe the whole problem on my situation is that I will support two different generation of this product using the same name. I understand better the
Angular 2problem @jeme reported.If I use a different name by generation, everything is fine. However, if I want to use the same name and keep supporting a previous generation, that simply doesn't work.
Thank for the help,
Best Regards,
Jonathan
@FichteFoll commented on GitHub (Sep 20, 2017):
Well, the fundamental motivation for this issue seems to be this:
Say you want to introduce a breaking change in major 1, the first question should be: "why?", then continued with: "Can't I just leave it in there? If I do API breakages regularly, maybe I should still be using pre-releases?"
After all, if you break the API of your major 1 product, people will have to investigate the changes and evaluate whether they need to update their code. In which case they might as well jump to major 2 altogether.
And finally, this all depends on your target audience, as in how frequently they can adjust to breaking changes and whether they depend on maintenance releases of major versions with bug fixes.
@JonathanMagnan commented on GitHub (Sep 21, 2017):
Thank you @FichteFoll , @jeme
Just to let you know that I have read your both answer and appreciate really the time you took.
I will take a few days to think about it as there is
proandconlike any versioning.One question though:
2.0.0if a lot of spelling mistake and text addition has been done since theSemantic Versioning 2.0.0has been released?Best Regards,
Jonathan
@majormoses commented on GitHub (Oct 18, 2017):
First off these are all excellent points and I echo them. Rather than giving another similar answer I will focus on the question about the semver spec following semver and what I believe the root need of what your user is asking for.
Well when projects choose to release is almost always at the discretion of the maintainers and what their community/customers wants. I am a maintainer for several different open + closed source projects across several different orgs. They all have different needs and resources which means that they often have different release schedules and cycles. For some of them we take the stance that a release should be cut on each functional change within 24 hours. Others we wait for a few new features before cutting a release. For things like spelling, typos, documentation, etc we wait until there is a functional change. Taking a quick peak at: https://github.com/mojombo/semver/compare/v2.0.0...HEAD I do not really see any new "features" and I am guessing that the value of versioning the spec with a bunch of patches that are not actually fix anything that a user would need to pull in is not enough to outweigh the cost of cutting a release.
I will avoid arguing for semver as others have already made great cases for it. I could totally be wrong but I think that your users are asking for something that is partially facilitated by semver; IMHO you could accomplish their needs with another versioning scheme that is more palpable to you. The more important thing is not which version scheme, it is more important that they understand the upgrade path. A responsible developer/operator will do some kind of risk assessment with varying levels before upgrading. Ideally it should not be required to have them read the entire source diffs and be a guru in your project to do so at the very basic level. The easiest solution is to provide this is via a understandable versioning scheme and a good changelog.
@JonathanMagnan commented on GitHub (Oct 18, 2017):
Hello @majormoses ,
Thank your for this additional information.
There is some stuff in which I could argue but at one point, it's more some personal opinion and doesn't add any value to the
Semantic Versioning.I will close this issue since there is nothing more I can add and I understand very well point everyone provided in this thread.
Thank a lot for your help,
Best Regards,
Jonathan