mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #340] Add another number to semver #2962
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#2962
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 @corysimmons on GitHub (Oct 25, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/340
People are always afraid to to do breaking changes because it means a major ver bump.
The very-real/valid problem is explained well in this presentation: https://www.youtube.com/watch?v=tc2UgG5L7WM
They typically store up 50 million commits in a separate branch they need to maintain, and then launch all these breaking changes at once.
Why not add a fourth field to semver specifically for marketing purposes?
1.9999.0->2.0.0.0could be marketed as "Holy crap! FooProj 2 is here! Check out the migration guide!"This might be a minor change (from
1.9999.0to2.0.0.0) but the only people who would know that are the people closely following the project.This would allow for the project to advance & iterate quickly, while encouraging more users to adhere to semver strictly -- directly in
masterin a lot of cases.I know this sort of change would require package management systems to upgrade and add another symbol for this sort of change, but I think it'd be beneficial:
Let me know your thoughts, but I've been thinking this for years and have heard other people independently wonder why this feature doesn't exist.
SemVer 3.0.0.0 pls! 😻
@glureau commented on GitHub (Oct 31, 2016):
I think devs are afraid to do breaking changes for a lot of other reasons, like explaining the breaking changes, documenting how to move from previous to new APIs, the potential bad feeling that could hurt old API users, the management of the transition phase (deprecated API for example), etc.
A breaking change have to be considered as something big when you already have a lot of users used to the "old" API, I don't think it's only on the major var bump.
As explained earlier, having a 4th numbers would not help them so much: they were probably not sure/happy enough of the API to use 1.x publicly, so I don't think they'll use a 1.0.x to say "you can grab it as a commercial version but it's still not safe/good enough for us".
I'm actually working on a project where we have multiple applications that defines a complete system. Each app has its specific version, and communication between apps have versionned API, but we used a public commercial name of "2.0" when some new features arrived. That's not impacting how we version our apps, it's purely commercial. (The only thing we wrote at this time was a mapping of all app/api versions, but it was only internal and nobody really used it.)
That's interesting, but I don't understand how this can work. A breaking change that is not breaking build? What's breaking then? Or you mean about deprecated stuff? In both case, I don't see the relation with the commercial number.
PS: I'm more a Java/Android developer, even if we try to release at least once every 2 weeks, but I understand than requirements for JS devs can be quite different. If you have more examples :)
@Exadra37 commented on GitHub (Feb 17, 2017):
This is why I think we need a version number for Backwards Incompatible changes.
The solution for my personal projects is to versioning like this to solve what SemVer is not addressing.
For PHP Developers using Composer on their projects with Semanting Versioning like
1.0.0.0will not be a problem as per this Composer Demo.For some other Programming Languages maybe their Dependencies Managers may need an update to handle the 4 digits Semantic Version schema.
So I vote for a
3.0.0.0SemVer.@colomet commented on GitHub (Apr 25, 2017):
I like in the @Exadra37 way. 3 digits makes the counter to work to fast and the most of thte times for no reason. Look to wordpress. They use X.X but the security release is X.X.X, the reason why is because nothing change in the code and they do not need to change the 2 digit.
If we use 3 digits and we have a Bug Fix, we will increase the 3 digit but nothing new appears in the code, a 4 digit will fix that and the people will understand nothing but security change.
@colomet commented on GitHub (Apr 25, 2017):
I just think bug fixes must be in a different number. Because the last number for backwards-compatible and bug fixes together is a bad idea.
What is a backwards-compatible? , some times that give us problems. It happen all the time, maybe by mistake but one new feature breack the site once it works with other code together (we work with pressbooks where some plugins can have incompatibilities). But a bug fix, change nothing in the code (don´t use to).
@Exadra37 commented on GitHub (Apr 25, 2017):
I am using this Semantic Versioning approach and my reasons for it can be found here.
A proof of concept of this approach working with Composer can be found here
@Exadra37 commented on GitHub (Apr 26, 2017):
@jeme
I just created my how specification because SemVer does not work properly to handle Software Development.
Sorry to say but SemVer concept is flawed and broken, that is why it has lots of bad implementations and lots of the big players don't use it.
I would prefer to see SemVer adopt the 4 digit :)
I will check that issue you mentioned... Thanks for pointing it out.
@sapioit commented on GitHub (Apr 29, 2017):
You can look at it this way:
If you're using random names for your variables, people can and WILL misunderstand what your code does. Sure, even if you use suggestive, explicit variable names, some will still misunderstand them, but their number is insignificant compared to when using random variable names.
And that's why SemVer is broken, forever. It enforces semantics to the point where logic breaks.
Also, Explicit Versioning is now the official name.
@Exadra37 commented on GitHub (Apr 29, 2017):
@jeme
Unfortunately SemVer refuses to accept the reality and all evidences that SemVer is a Versioning Schema widely used in the wrong way, due to is nature of implicit naming in the schema concept.
Sadly instead of seeing SemVer recognizing the reality and evolve to a better schema with 4 digits and release it as
3.0.0.0a new Versioning Schema was forced to emerge Explicit Versioning.I continue to hope that in future SemVer can reconsider is position.
@sapioit commented on GitHub (Apr 29, 2017):
No, it might have been the way you hammered it, which is the way you moved from one version of the nail being in the wall to another version of the nail being in the wall.
By not having an explicit enough set of guidlines, you failed to solve the problem you had, and are now blaming the tool (the hammer, the language, the framework, the CMS, etc.) while the problem was following improper guidlines for getting from one stage (version) of the hammer being in the wall to another.
Analogies are good and all, but sometimes they're a great way to find gaps in logic. That's one of the reasons why they're so widely used, alongside allowing for easier understanding of concepts through the usage of situations that are similar (to the ones at hand) from certain points of view.
And yes, misuse of a tool IS evidence that your tool might not be designed well, and more so if the accounts of the tool being misused are far outnumber the accounts where the tool is used correctly.
That is, to say, your tool is good, and solved a problem, but it's not the best tool for the job, and the solution is (or leads to) more of a temporary fix than a permanent solution, exactly because it leaves room for interpretation (has a lot more moving parts which can and WILL break, has a much higher cyclometric complexity allowing for misunderstandings which lead to other problems).
@colomet commented on GitHub (Apr 29, 2017):
@jeme there are different type of software with differnt needs. Some people need semver, some people need 4 digits
@Exadra37 commented on GitHub (Apr 29, 2017):
@jeme
You haven't even read the Explicit Versioning specification schema that clearly states that the first 2 digits are representing 2 complete different stages in Software Releases.
Of Course you will have always persons using it wrong... you just need 2 persons in a room and a sentence to have a chance off 2 different outcomes. More explicit you write the sentence less difference or no difference at all will come from the interpretation of it.
And I am not worried about Explicit Versioning popularity related with SemVer, because normally people follow the crowd, aka SemVer, without even know where the crowd is going or if a better path exists.
Remember that is not always the majority that as the reason on their side...
As I said before I would prefer SemVer
3.0.0.0hover having to use another specification to address the ambiguity in SemVer.But as in fan clubs discussions we will not go anywhere, because a fan club person will never recognize the evidence, therefore and sadly I am done here :(
@colomet commented on GitHub (Apr 29, 2017):
@jeme is a pity, because some of us believe with a modification, we will not need more specifications. One could fit all of us.
@Exadra37 commented on GitHub (Apr 29, 2017):
@jeme
Firing back on your own words, SemVer says
YourScrewed.YourScrewed.YourScrewedbecause not every Software using SemVer applies breaking changes in the same way. They release them in any of the 3 identifiers.And thanks for pointing out me issue #321 that made us get together to start a new specification that could preferably be adopted by SemVer as the next release
3.0.0.0.But keep in mind that I am not wanting to offending you with the fan analogy... I also have fall on the same trap at some points in my live and for sure I may fall again in the future ;)
@Exadra37 commented on GitHub (Apr 29, 2017):
@jeme
You made me laugh so loud :)
Explicit Versioning is all about to be VERY CLEAR WHEN INTENTIONAL BREAKING CHANGES OCCURS, that is what SemVer is far to achieve, once it mixes Major releases with Breaking Releases in the same identifier, where Explicit Versioning separates that 2 situations into their own identifiers.
And all the rest of what you said just confirms what I been saying, SemVer is ambiguous and open to several interpretations.
NPM problem is not SemVer versioning schema, is just a immature Package Manager.
Php Composer also relies on SemVer and works fine with 3 or 4 identifiers.
@jeme commented on GitHub (Apr 29, 2017):
REDACTED
@Exadra37 commented on GitHub (Apr 29, 2017):
@jeme
Yes I read it and I already posted in this issue several times the link WHY SemVer is ambiguous and mixes major overhauls in your Public Api with intentional breaking changes, please read it.
Now lets's stop here, because this is becoming like discussing the sex of angels... another analogy without offense ;).
I will continue to apply Explicit Versioning to my projects and you SemVer and happy days for everyone :).
@Exadra37 commented on GitHub (Apr 29, 2017):
@jeme
Quoting like you have is misleading what I have said...
Correct quote:
So now that we have a better context we can see that i refer to an Overhaul in the code as one that introduces major change into the Public Api, that is backwards incompatible, therefore completely different from what you where trying to induce in my affirmations.
Now please relax and enjoy a 🍺 and let's continue our lives, unless you want a rant for the eternity 😄
@Exadra37 commented on GitHub (Apr 29, 2017):
@jeme
I don't need to read it again, maybe you should do it again and you will see that at any point I say that MAJOR SemVer definition is not the one you have said:
What I say is that I don't agree with the definition used for SemVer MAJOR identifier and it should be splitted into 2 identifiers.
That said, have an happy day and enjoy the long weekend 😎 .
PS: when visiting Scotland stop by Edinburgh and we will have some 🍻 and start another rant in other topic 😃
@krzysiekpiasecki commented on GitHub (Apr 30, 2017):
Hi all,
It's all about API not a product (release). It's all about producer and consumer.
Software versioning should never be used for marketing. Want to sell me almost the same product as a new?
Introducing an additional number for incompatible changes is just an attempt to circumvent an imaginary problem and is not conducive to software tampering and stabilization. What is the difference if the software has version
1.9999.0or9999.1.0- this is the version number not a product name.You can quickly go to version 1.0 whenever you are ready.
Until you're not
1.0you can iterate as fastest as you want. Then you're1.0and clients expects, that you will not break API. Otherwise you increment major and consumers follows you or not.@sapioit commented on GitHub (Apr 30, 2017):
So don't use it, then. Nobody forces you to do so. You can use whatever the heck you want.
No, the fact that you refuse to accept that Explicit Versioning might be the right tool for SOME people makes you a fanboy.
So what would a Major Release WITHOUT breaking changes be? Like, the exact same code except dropping support for the previous version... It's not breaking anything, and everything works just as before, being the exact same code, with the only differences being the version number and the dropping of support, which, again, does not break anything.
Again, the first number of the 4 represents the version the USERS of the product should care about, with everything else done by the updater of the product.
Except for the developers, where any change can change the way they need to write code. If you add one variable to a function or method, you have to add it everywhere in your code. And more so if the code overhaul changes the system logic of your code.
Too bad everyone does that. In fact, that's one of the MAIN uses of it's use. The same product, except with this one you can get upgrades, while the previous one will get none.
Explicit Versioning is aiming to be both more developer-friendly and more user-friendly.
Also, I think we should add the usage of 0a.x.x.x (a for alpha, b for beta). And I still think the first number shall be used mainly for dropping the support of previous versions.
And even if you reach 36.x.x.x, what's the problem?
@sapioit commented on GitHub (May 1, 2017):
A backwards-compatible overhaul can increment the Compatible, or the Release. However, there is also the difference in the workflow, which can break compatibility with the previous workflow. If you switched from MVP to something else, the compatibility is broken because the developers need to adapt to the big change.
By the way, what language is the code in? The function-in-function is not a good practice for programming in general, even through I understand that
innerFuncis only loaded whenmeFuncis also loaded, but many languages don't have or don't recommend that. Not questioning the code, just curious what the language is.And yes, I undersand what you do, but some languages allow adding parameters without having to call them, except if you have them added in a way that makes the calls' order changed (i.e. adding them in the middle or at the beginning).
@jwdonahue commented on GitHub (Jul 14, 2018):
@corysimmons, I think if you search for and read some of the many other threads that suggest adding one or more digits to the SemVer, you'll find that SemVer stake-holder sentiment runs against the idea. Some of the proposals are actually worth considering for write-up and implementation as their own competing standards, but none of them really fit well with SemVer.
Unless you have questions or intend to proffer a PR on this matter, please close this issue at your earliest possible convenience. Thank you.
@corysimmons commented on GitHub (Jul 16, 2018):
I didn't read this thread but I'm assuming people aren't into the idea by the thumbs down so why write a Semver 3.0.0.0 spec??
Browsing through thread, the arguments against more description in versioning can be applied to Semver2.
My original proposal:
Semver2:
If semver is gonna be purist with what matters in a versioning convention then deprecate in favor of the much easier/more logically sound comver:
Breaking.NotBreakingAnother approach would be to simply change Semver meanings to get the best of marketing + relevant information:
Marketing.Breaking.NotBreaking<-- this would be nice but would break everything too much...1.2.3.4or1.2wouldn't break as much stuff.I do think a marketing version is infinitely more important than two descriptions devoted to non-breaking (i.e. the
NotBreakingWithSomeDescription. NotBreakingWithAnotherDescriptionin semver2) but I no longer expect large projects that aren't maintained by huge corporations to evolve though so happy to close and let us all get back to work.Edit: Actually, any versioning system should be easy to upgrade with a symbol within the version.
Marketing.Breaking.NotBreakingcould become@Marketing.Breaking.NotBreakingwhere@simply denotes this specific package is using Semver 3.Not sure what to do about someone who is stuck on an old version of npm (or whatever), maybe they can manually maintain that package's version number as something that won't break their installer? e.g.
Breaking.NotBreaking.0??Bestest thought (I think):
Since it doesn't really matter where a marketing version goes in a version... an easy upgrade path would be
Breaking.NotBreaking.MarketingUsers could have
999999.999999.2to signify they were using Angular 2 and it'd never break a thing.As semver maintainers all you'd have to do is make Semver 3.0.0 be
Breaking.NotBreaking.MarketingOr0. Maintainers using Semver 3 would just advertise their releases as "Angular 2".@sapioit commented on GitHub (Aug 8, 2018):
Actually, I think it does matter where the marketing version goes, because you can't sell
Semver v3while when looking through the versions list you seev86.61.3. Even if that last.3is the same, people need to be taught to specifically look for that one. That's why I think the marketing digit should be to the left of the rest, as the dominant digit. Sov3.86.61would make more sense for someone who did not read the semver documentation in detail.The point is to make things easier, not harder. Which is why I'm in favor of Explicit Versioning. More about it here.