mirror of
https://github.com/semver/semver.git
synced 2026-03-09 07:22:04 -05:00
Suggesting a fourth number to indicate project generation #142
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#142
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 @lolmaus on GitHub (Jul 21, 2014).
There's already a thread #200 discussing the necessity of extending the three-number SemVer notation to indicate tiniest nightly changes. In this thread i would like to discuss the necessity of the opposite: extending the notation to indicate fundamental changes.
I think that the main reason why developers are so reluctant to adopt SemVer is due to the fact that most of them use the major number to indicate project generation. They only change the generation version when there are ideological changes, very significant improvements or a major rewrite of the project.
And with SemVer they see the major version escalate really quickly, which makes no sense to them. "A slightest change in order of args of an API function that nobody uses -- and i'm ought to release version 2 of my project? That's boolshit! I'm not going to bump my project's version in next couple of years -- because it's not going to have any fundamental changes or updates."
There are a lot of large projects that don't follow SemVer, and i think exactly for the reason outlined above. I can name Sass -- a preprocessor used by dozens thousands web developers.
The only workaround of this problem that is compatible with SemVer's three-number notation and that i can think of is embedding the generation number into project name, e. g.
Foobar2 v.8.3.12. Some package managers do that already, e. g. Ubuntu hasapache2package.But currently in our
Gemfile,package.json,bower.jsonfiles we have to remember which dependencies follow Semvermajor.minor.patchand which follow the traditionalgeneration.major.minor. This is a tedious thing to take care of, and we seebundle updatebreaking our projects much more often than it should. The struggle is real!I think that introduction of the fourth number into SemVer notation will resolve this problem. This number could be arbitrary, e. g.
Foobar 3.2.1indicates major version 3 of the first generation of Foobar, andFoobar 2.3.2.1indicates major version 3 of the second generation of Foobar.This feature will allow most developers follow SemVer without escalating their project version (generation number).
@FichteFoll commented on GitHub (Jul 21, 2014):
While I agree that the "generation" thing is widely used, even though mostly unconsciously, I definitely prefer the
foobar2 3.2.1approach.Comparing
3.2.1to2.3.2.1is not transparent and, according to the spec for pre-releases for example, the first is actually higher than the latter version. By making the generation optional and defaulting to1you create unnecessary confusion where the version's actual precedence depends on its lenght prior to the values of the individual fields.The only way to prevent this is to require the generation, but this on the other hand will lead to a leading
1.that is not going to change for 80% of all software, probably (I'm guessing here). In that case, if are planning a complete rewrite and do not want to just increase major from 21 to 22, you should rename the package imo. Because tbh it is an entirely different thing anyway.@lolmaus commented on GitHub (Jul 21, 2014):
Let's split this discussion in two branches?
generation.major.minorpractice?@lolmaus commented on GitHub (Jul 22, 2014):
VirtualBox is embedding two numbers into package names:
And they're using the traditional
generation.major.minor, not SemVer.@JoergWMittag commented on GitHub (Aug 14, 2014):
dpkg/APT has the concept of epoch. It's not the same thing (it is used if the version numbering of the upstream package changes, i.e. it is kind of a "version for the versioning scheme"), but somewhat related. The syntax is epoch:major.minor.patch, and an epoch of 0 is assumed if missing.
@peterjenkins commented on GitHub (Aug 15, 2014):
@JoergWMittag Thanks for the info, good to have another perspective. I'm following this issue because I do think it's something that turns people off to semantic versioning, whether or not they're right to be turned off by it.
I agree that people like to have an emotional attachment to version numbers, and they might not be "ready" to go to 2.0, even though they want to break backwards compatibility. And they probably don't want to change the entire package name... that's going to break consumers of the functionality.
At the same time, I'm sure the complexity of semver turns some people off already, so adding another component is another thing to understand. Still think it's an opportunity to provide a better match for people's mental schemas if there was a good solution to this.
@lolmaus Thanks for filing the original issue.
This matches my experience of how people want to use version numbers. They want to "save" version 2.0 until they feel the software "deserves" it.
@drewcrawford commented on GitHub (Aug 30, 2014):
I'm piling on since this issue is the best I can find already filed that adequately expresses my objection to semver. But if you tell me to file a new issue I will do that instead.
The objection boils down to this. There a variety of different types of "breaking changes":
SemVer forces me to consider any breaking change as "major". But I suggest that calling case 3 and 4 (and debatably 2, although it depends) a "major" change is actually an inaccurate characterization of the update. In the ordinary rules of English, these are minor changes. Breaking changes, but minor breaking changes. Because "breaking/nonbreaking" and "major/minor" are really two independent ideas, that SemVer incorrectly tries to collapse into a single integer.
What SemVer essentially encodes is "did the API break? Y/N" But what it doesn't encode is "How much did the API break?" or "How long will it take me to fix the API break?" or "How much of my afternoon will I spend fixing this API break?"
The result of this is that users are forced either to either take all updates, no matter how radical. Or else they are supposed to lock to a major version and turn away all API breaking updates no matter how minor they are or how unlikely it is that it actually affects them. As a practical matter, these two choices can be pretty close to just accepting all updates or accepting no updates, which does not require SemVer at all.
A 4-level scheme draws some distinction between different severities of breaks. Something like
Would give you 2 levels of breaking changes (major and minor) and 2 levels of nonbreaking changes (compatible and patch) and this gives the user and package author some flexibility. They can allow breaking changes that the author thinks are minor, for example.
There are a long list of real-world projects that use "minor" in exactly the sense that I'm using it here, to mean breaking but not-very-large changes. Python, Rails, Django, OSX, Postgres, etc., all have a concept of "minor" breaking changes that break some software somewhere, but probably not yours. As opposed to a "major" break, that more likely breaks your software.
Giving two full fields to the breaking changes such as
major.minor(orepoch.major, although I still think "major" is a poor word choice for a small breaking change) would also, I think, solve the problem of "I don't want to go to 2.0 until a lot of things have changed" mentality.@rlidwka commented on GitHub (Aug 30, 2014):
Widely accepted naming for 4-component version system is "major.minor.micro.patch", just saying.
@lolmaus commented on GitHub (Aug 30, 2014):
@pjenkins-cc,
topicstarter here.
The reasoning behind current SemVer implementation makes perfect sense to me: it allows to write version restrictions for your project's dependencies so that seamless upgrades are possible, guaranteed not to break your project.
When you have half a hundred dependencies in your
Gemfileorpackage.json, a possibility of automating the upgrade process is a big deal.But when a dependency is introducing a breaking change, no matter how minor, neither the SemVer standard, nor your package manager, nor your framework have the ability to determine whether the breaking status can be safely ignored or not. This can only been determined by human interaction. Thus, the decision to undertake every single upgrade to a breaking version can only be made by a human, never by software.
There is no way SemVer is ever going to violate this. I think it's useless to ask for that.
Here's my understanding of the current three-digit versioning scheme:
SemVer calls those components as "major, minor, patch". It might not be very self-explanatory, but for the sake of compatibility, i believe that we should not advocate for changing the existing convention. I think any attempts to do so will be turned down.
That's why i'm suggesting to introduce a fourth component that will not change the current convention but add to it. My idea is "generation, major, minor, patch", as outlined above. The traditional "major, minor, patch" part will be left as-is, without breaking the existiing wokrflow. The new "generation" component will be given away to project authors to increment whenever they feel to.
@drewcrawford commented on GitHub (Aug 30, 2014):
We've reached an impasse. It may very well be the case that SemVer won't deviate from "minor" meaning "nonbreaking".
However it's equally the case that LOTS of software (Python, Django, Rails, OSX, Postgres) won't deviate from "minor" meaning "breaking".
As long as those two statements are true, I have to conclude that SemVer isn't the standard for me.
@rlidwka commented on GitHub (Aug 30, 2014):
Yeah, some people even promote ferver where only patch number is guaranteed not to break anything.
@lolmaus commented on GitHub (Aug 30, 2014):
@FichteFoll
That's not the only way. Another way is to use a different syntax. I can think of
2:3.2.1, but it's not filename-friendly, so another suggestion is2-3.2.1. We can come up with any syntax that is explicitly SemVer2-invalid, to avoid any confusion.I still like the beauty of
2.3.2.1, though. It's what users want their versioning to look like. I don't think it's criminal to have SemVer3 follow a scheme that would confuse SemVer2. In everyone'sGemfileandpackage.jsonthere already are dependencies that violate SemVer2, sometimes dozens of them. Also, introducing2.3.2.1in SemVer3 will help reducing the number of projects violating SemVer.@lolmaus commented on GitHub (Aug 30, 2014):
@JoergWMittag
That's an interesting approach. If this approach is used for SemVer, the "epoch" should reflect the SemVer version used to format the version number. Would be very bulky, but remarkably explicit.
semver:generation.major.minor.patch@lolmaus commented on GitHub (Aug 30, 2014):
@rlidwka, is ferver for real or a joke?
@rlidwka commented on GitHub (Aug 30, 2014):
@lolmaus , the name might be a joke, but everything else is surely real.
It isn't a standard or anything, it's just a way for npm packages to minimize an amount of the damage semver does (I mean, semver is not useful everywhere, but it is forced upon all npm modules).
It's just the notion that majors break, minors might break, and patches never break.
jshttpuse it and call "ferver".docpaduse it and call "real semver" (see here).coffee-scriptused similar versioning system even before those two came out.@lolmaus commented on GitHub (Jan 10, 2015):
This: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e
@FichteFoll commented on GitHub (Jan 11, 2015):
Coming back to this (because of activity), the linked text and discussion does not really provide a lot of input to this issue that isn't already known, but it highlights the likely only flaw of semver: It's not about "human feeling" or similar. If you are about to rewrite your entire software from scratch and would like to not release this as
8.0.0right next to your comparably minor but breaking changes in7.0.0, you can't do that currently. Well, you can in a different way: Release it as a new project.To put it bunt: If you previously worked on
pproject (7.1.8)and then worked on a rewrite, you could release that aspproject2 (0.1.0), and treat this as a new project with its own pre-1.0.0 phase and a version number reset. I know that this has been done historically but it was never really brought into this context.Which leads to my conclusion: In inclusion of an "epoch" or "generation" number in semver is not needed practically (you can do the same thing in current semver by just increasing the major like always and then working with pre-releases) but would probably look and feel more satisfying for both developer and users. But then again, just renaming the project by itself solves the same issue, only without the clear specification of the successor.
In any case, if this was to be implemeted or considered it must be optional and use a different syntax/symbol.
-+are used already,~I'd like to reserve for the metadata if+gets moved to being a post-release itentifier (as suggested here: https://github.com/mojombo/semver/issues/200#issuecomment-47330860). Which leaves us with%_!^%#$&@and maybe more._&^sound like the best out of these, but^is commonly used as a version selector operand already and_creates kind of a big gap. This may or may not be desireable.@backspaces commented on GitHub (Mar 22, 2015):
Gentlemen, please.
SemVer is nice. It expresses Intent, which like DRY a Best Practice. I like Intent.
However, me using SemVer does not mean my dependencies do. Thus I cannot depend on my dependencies following the same SemVer semantics.
Case in point. I use gulp-coffee, restricted to its current major SemVer number. However, it uses the latest CoffeeScript. But when CS transitioned to 1.9.0, it made a breaking change (@parameters in method arguments). But gulp-coffee simply uses the latest CS. Bam, my project died and my 10,372 clients died with it.
This is a simple Transitive Closure relation over the set of my dependencies. Recursive semantics if you'd like. Computer Science.
And it is not easily solved. I believe at least in NP.
So just be warned: when you use SemVer, you are being very nice and we love you for expressing Intent. But it offers no guarantees that your dependencies do and even more simply, that you can express in SemVer semantics just what your dependencies responsibilities are! I'm not sure it is even easily expressed.
It's nice, but offers no hope yet at full package safety.
@lolmaus commented on GitHub (Mar 23, 2015):
@backspaces, SemVer gives full package safety when all your dependencies and their dependencies follow SemVer (and provided that no dependency maintainer makes a mistake).
When not all your packages follow SemVer, the safety is not full. But the more packahes follow SemVer, the safer your project is.
Aniway, this discussion is irrelevant to the thread.
@ELLIOTTCABLE commented on GitHub (Apr 6, 2015):
A surprisingly large minority of people dislike SemVer, in my experience. A much smaller minority actually choose not to use it, mostly for the reasons described above.
Until the Right People decide to take the widely-discussed issues mentioned above seriously, here's the approach I've been using for my projects:
major_breaking.minor_breaking.majorUnbreaking-minorUnbreaking(and/orgeneration.breaking.minor-patch, if you prefer) system described above in all documentation and internal versioning logic for a large project,Coolproj 2.13.3-142encodes to npm as{ "coolproj2": "13.3.142" })This has the additional benefit that, assuming SemVer or npm don't change to accommodate any recognition of API ‘generations’, that matching on the generation-field always defaults to “don't accept” for every consumer. When you push
Coolproj 3.xfor the first time, even users with"coolproj2": "*"won't receive that until they've read the description of the New Way of Doing Things™.Unrelated to my hack-tip above, there's an actual argument for ‘generation’-level versioning that hasn't been brought up before.
SemVer, as currently designed, assumes versioning in a vacuum: more specifically, that the meaning of your project's version number (that is, the current version of your project) depends on nothing more than: 1. the JavaScript API of your project (or rather, since this is the only type of project that SemVer covers, your ‘library’), and 2. the JavaScript-API-chunks (other libraries) that your project depends on. (
s/JavaScript/yourlang/as necessary.)However, prior to SemVer, version-numbering encoded more, not less, data for several large classes of project. Let's try and collect a small selection of projects for which this has been inadequate:
RubyParserbecomesRubyParser 2when it becomes able to parse Ruby 2 source-code.BadassBrowserDebugger 7.xbecomesBadassBrowserDebugger 8.xwhen Safari 8 is released and supported, despite the API remaining largely the same.And, of particular interest to me,
Lang.js 3.xneeds to version as greater thanLang.js 2.x, even when there's breaking changes toLang.js's JavaScript API in between breaking changes to it's Lang API. (Orhttp-parser 1.xbecominghttp-parser 2.xwhen it supports the HTTP/2 specification. You get the idea.)Yes, these things can be encoded outside of the version number. That's not the point. Having these things encoded in the version number is the perfect trio of
(useful to machines / useful to human users / an accepted practice prior to SemVer), and thus I feel it's important for SemVer to take the desire for a ‘generation’-byte seriously. /=@ELLIOTTCABLE commented on GitHub (Apr 6, 2015):
One last footnote: I'm not at all averse to hacks/solutions that don't inconvenience existing users of SemVer. Is supporting
"coolproj": "2.13.3.142"difficult to do in a backwards-compatible way? Then let's not! I'm all for using the apparently-already-existing ‘epoch’ formatting mentioned above (2:13.3.142) … or, to get even more radical with it, how about whitespace as a seperator? ?"coolproj": "2 13.3.142"is pretty attractive to me, but maybe that's just a personal quirk. :P@bperrybap commented on GitHub (Jun 7, 2015):
I've said this before and I'll say it again. I think it was really dumb to create and specify such a hard coded strict 3 number version system.
With a tiny bit of flexibility (and better parsing) the numbering system could be an arbitrary length.
And when comparing version numbers, if the number of specified numbers differ, then the unused numbers in the smaller version number are just filled in with zeros for the comparison.
I mean all these rules about versioning are really supposed to be about comparing version numbers for the purpose of dependency checking so why be so be so needlessly strict?
So for example, when you have 1.0 vs 1.0.0.0.0.9
1.0 would be considered before 1.0.0.0.0.9 since 1.0 is the same as 1.0.0.0.0.0
With an arbitrary (ok perhaps limited to something reasonable like 10 or 16) number of versioning digits then users can have their extra version information and semver can be much more tolerant and compatible with other versioning systems that are already in use.
For simplicity in the parsing and comparison code, it could be limited to say 10 or 16 digits and then all numeric version comparisons are done against all 10/16 digits and the unspecified digits are just filled in with zeros.
It makes absolutely no sense to me that semver should be so strict, when there is a way to provide what many people are wanting and yet still be compatible with the existing semver semantics.
The only reason I can see is stubbornness on the part of certain people that want to mandate that everyone adopt their way of thinking.
--- bill
@ELLIOTTCABLE commented on GitHub (Jun 8, 2015):
@bperrybap why 1.0 → 1.0.0.0.0.0.0.0, and not 1.0 → 0.0.0.0.1.0?
in real-world projects, I'd vastly prefer the latter. 1.0 for small projects, which then compares as 0.1.0 when I release a stable, official version of the project that I'd originally expected to be small and simple … and then 1.0.0 compares as 0.1.0.0 when the project gets completely re-designed breaking all sorts of backwards compatibility and we move up a generation to 2.1.0.0 … you get the idea.
Also, it's really important for the entire point behind SemVer (versioning for machines, not for people) that some number of the digits be restricted to non-breaking changes. As described above, I think we should declare the "last two components" as non-breaking, and then allow arbitrary breaking numbers to the left of that … but whateveryoud propose a solution to be, there needs to be one.
I think some of these start to show why the SemVer guys didn't pay much attention to extendibility concerns. :P
@bperrybap commented on GitHub (Jun 8, 2015):
The problem with the unspecified digits being on the left is you have to know how many digits there are in order to do the comparisons so you are right back to what is there today.
i.e.
If somebody specifies a version as "1" how does that compare to "1.0, or "0.2"
In your model: (using 4 total digits just as an example)
1 would be 0.0.0.1
1.0 would be 0.0.1.0
0.2 would be 0.0.2.0
So you can see the ambiguity which makes it impossible to compare.
I don't see how that can be made to work.
In my proposed model:
1 would be 1.0.0.0
1.0 would be 1.0.0.0
0.2 would be 0.2.0.0
And there is no ambiguity.
1 is the same as 1.0 which is what you want.
and 0.2 is before 1 and 1.0 which is also what you want.
By placing the unspecified digits to the right, you allow digits to be left off and all the existing rules for significance in semver still come into play and work exactly the same.
i.e. it doesn't strictly require exactly 3 digits and even allows more than 3 digits but yet still allows the existing rules that specify that the left most digit is the most important and the significance reduces as you move to the right.
The only difference is that it doesn't restrict the total number of digits to 3.
The method that you proposed breaks that or requires that you know how many digits are used.
What I was proposing was a simple way to provide a mechanism that isn't restricted to exactly 3 digits that is fully backwards compatible with all the existing rules.
In terms of which version digits specify that things "break" all that still works exactly the same when you push the unspecified digits on to the right end. That way you always know where the breaking digit is regardless of how many digits are specified.
i.e. if the left most or 2 left most digits specify that it breaks compatibility, then that remains a constant regardless of how many extra digits are used to the right.
@crazedsanity commented on GitHub (Jun 8, 2015):
I don't see any reason why someone couldn't extend SemVer to accomodate such a version number... but I see no reason to alter SemVer itself. Just my two cents.
@JamesMGreene commented on GitHub (Jun 8, 2015):
@ELLIOTTCABLE Sorry but putting the extra zeroes to left makes absolutely no sense to me (and many others, I'm sure) without having a fixed number of segments (e.g. like an IP address, or current SemVer). Otherwise, version comparisons won't ever make mathematical sense as you would have infinite oddities, e.g.
1 < 0.2.@bperrybap commented on GitHub (Jun 8, 2015):
I believe that semver should be about numbering system that specifies how to interpret version numbers and I think it is also a good thing to specify a numbering scheme that can also convey compatibility and backwards compatibility.
This allows doing things like automated version dependencies.
What I have never understood is why semver took the myopic view of limiting the versioning digits to exactly only 3 digits when it is trivial to extend to a more general case to allow not only more than 3 digits but also a variable number of digits including less than 3 digits and even allow interoperability between versioning schemes that use a different number of total digits.
i.e. there seems to be no need to make such a limitation when it can be done in a way that is completely backwards compatible with all the existing rules.
And by updating the numbering scheme to cover the general case, lots of additional people would come on board which is very good thing from a standardization point of view.
Seems to me at this point more energy is being being spent fighting the battle on both sides for and against making the change then the amount energy to simply update the parsers to support the more general case of a variable number of digits.
I still don't understand the objection.
@JamesMGreene commented on GitHub (Jun 8, 2015):
Remember that in SemVer's
x.y.z,yis an incremented revision ofx, andzis an incremented revision ofx.y. This fits with the concept of subsequent segments being decimal/fractional additions to their preceding segments -- this coincides with the idea of adding infinite.0segments to the right (decreasing [sub-]decimal place values).Adding infinite
0.preceding segments fits roughly with the concept of decimal multipliers (base 10).While those two mathematical concepts are essentially the same concept, the former fits with SemVer's existing logic; the latter does not.
@bperrybap commented on GitHub (Jun 8, 2015):
@JamesMGreene
Which is exactly what I've been saying for months.
You can have more or less than 3 version digits as long as the unspecified digits are assumed to be to the right and are zero, when not specified, for the purpose of comparisons.
The only somewhat sticky part is to define how to handle the backward compatibility version digits when there are more or less than 3 digits but that is easily defined and can be left as it current is.
So for example if somebody is using only a 1 digit version number, then each version would be assumed to be incompatible with the previous version since the most significant version number is being changed.
@ELLIOTTCABLE commented on GitHub (Jun 8, 2015):
@bperrybap … SemVer already doesn't make ‘mathematical sense’, as you put it. It's not a decimal (there can't be more than one radix.), it's a series of segments.
Er, what? Where's the logic for that?
0.2would compare the same as0.0.0.2or0.0.0.0.2.@JamesMGreene same thing. What's wrong with a completely-un-clarified
1(no other sections) comparing as0.1when compared to0.2, to use your example? And again, who cares if the only-two-modals that can possibly be parsed as decimals (incorrectly, as a version is not a decimal number, it's a tuple) will nonsensically compare when that is (again: incorrectly) done?As for your second post, I don't see how extending-least-significant ‘fits’ the existing use-cases better than extending-most-significant. For instance, please show me a real-world example of a project needing a ‘sub-minor’ versioning integer, that isn't solved better by adding build-numbers (or commit IDs or similar) to the end … meanwhile, there's plenty of pre-existing arguments listed above for a generation integer, increasing the expressivity of the most-significant end of the tuple.
More than anything else, maybe it's time to open a second Issue for ‘extensibility’, where this can be argued; if your suggestion were to win out, it wouldn't solve any of the issues already listed and discussed in this particular Issue, and even if we had
major.minor.patch.<extensible>(despite my personal lack of understanding as to why that's useful), then we'd still need to extend the that system with ageneration...most-significant-integer. (I should point out that that will be an absolute mess, because while it's easy to design a backwards-compatible semantic for one end of the tuple gaining new elements … adding new elements to both ends, I cannot see a way to do without breaking backwards-compat.)@FichteFoll commented on GitHub (Jun 9, 2015):
I don't see why there would be a use case for extending more fractional incremental updates than what currently is the smallest fractional update: a patch. It seems that people try to increase version numbers by "code change" and think they need separate numbers for 1-character changes, 1-line changes, 2-10-line changes, file changes, etc., but that is not what semver is about (and also pretty subjective and unstandardized).
One of the positive things of semver currently, imo, is its simplicity and conformity. It's always a 3-tuple of major.minor.patch and each has an associated meaning. I wrote down my opinion on an additional generation (or just "fourth") number earlier. It must either be optional and use a different separator than
.to be easily distinguishable or be required, which is not practical since rarely do people need the generation number. However, I am not convinced this is needed at all and can't be done with other means.@ELLIOTTCABLE commented on GitHub (Jun 9, 2015):
@FichteFoll I'm mostly with you; and I still think the best way to do this (short of completely re-designing SemVer to be extensible, which I'm honestly not that interested in), is to use
-. Despite it already being used, it can only be used at the end of the tuple, currently; so I don't see why we couldn't include it at the beginning, with a different meaning.(Although I personally prefer
2-1.0.6, I don't actually see why you think2.1.0.6isn't possible … and I similarly don't see a reason why it would have to be required, if it were supported. Why can't1.0.6, with three segments, simply compare as0.1.0.6? Or1.1.0.6, or whatever was desired/agreed-upon?)@bperrybap commented on GitHub (Jun 9, 2015):
@ELLIOTTCABLE
You are correct on the 0.2 being 0.0.0.2 etc... (my mistake)
I guess the biggest difference is that my assumption is that "1" is the same as 1.0 or 1.0.0 and so "1" is release that is after "0.1"
In your model this does not seem to be the case and so I have no idea how the numbering works in your methodology.
There should be no need to make 0 special. It should just be another number.
Here is my biggest complaint with semver and I think this may be what is leading others to want additional digits (tuple members).
Currently under semver there seems to be an assumption that there are "pre release" versions that build up to a released version. But there is no accounting for post release development release version numbers.
And THAT is what I think the real problem is.
From my reading of the current 2.0.0 semver spec there is no way to indicate in your version string that this is a post release "in development" version that is after a given release.
i.e. you have create a new release number and then you run into the issue that since it is active development then you don't know what number to pick since the feature set is not locked down yet, and then if things get backed out for the final release, you can have a backward compatibility issues with a previous unreleased release. etc... yada, yada, yada.
For various reasons, there are times when you need to be able to create version strings for s/w that will not be released. And it seems that semver does not have a way to deal with this.
If it does, then it isn't obvious and needs to be described on the semver page telling people how this could be done.
All of what I've seen is about versions leading up to a given release.
So what I'm guessing is that this lack of support for development versions and builds is a real back breaker for some people and that is why they want additional tuple elements added.
For example, to automate things, what I'm looking for a way to create a semver compliant version string that I can create from something like the output of a "git describe".
It is very unfortunate that you can't directly use the git describe output directly, when a semver compliant tag is used - That would be great and I think solve this issue for some people.
So while I can create a semver compliant string from "git describe", there doesn't seem to be a way to indicate that the version is beyond a given base release without creating a new tag/version number.
And then you are back into the issue of what new version number do you pick.
I don't want to have to create a new version and tag just to create an internal development release.
So my take is that much of the desire for additional tuple members is that semver doesn't seem to support post release devleopment builds.
@FichteFoll commented on GitHub (Jun 9, 2015):
@ELLIOTTCABLE
It's mostly uncommon practice to implicitly omit numbers at the beginning. The other reason is ambiguity.
1.0.6,0.1.0.6and1.0.6.0are just too similar at first glance and some people will be confused as to which side the numbers should be aligned. Thus, it should either be required or use a different syntax. Being required has many downsides so a new syntax is the only viable option imo. A hyphen would work.By the way, the human mind internally counts in chunks of 3, which means it can easily count the number of numbers in conventional semvers but needs to do a little stunt for the 4-number version.
@bperrybap #200
@ELLIOTTCABLE commented on GitHub (Jun 9, 2015):
@FichteFoll I think you and I are on the same page, here. 👍
@bperrybap commented on GitHub (Jun 9, 2015):
@ELLIOTTCABLE
Uh... I don't see that. From my reading you seemed to want to leave off numbers from the front of the tuples, and @FichteFoll said that wasn't a good idea.
What am I missing?
@JamesMGreene commented on GitHub (Jun 9, 2015):
@FichteFoll: Hyphen is already taken for prerelease versions, of course, so that's not viable.
@bperrybap: Indeed.
@JamesMGreene commented on GitHub (Jun 9, 2015):
By the way, please take a look at this related issue that I opened, discussed, and ended up closing: #242
The discussion may be more specific to my particular use case (wrapping an external dependency) but there's definitely a substantial amount of merit/insight to be gained within, IMHO.
@FichteFoll commented on GitHub (Jun 9, 2015):
@JamesMGreene yes, hypen is also used for pre-release, but
2-1.0.2-alpha.1is distinctive enough imo. Of course, a different symbol would be preferrable.@ELLIOTTCABLE commented on GitHub (Jun 11, 2015):
Honestly, I think I like the threetuple-of-threetuples feel of
5-4.3.1-deadbeef, now that I think about it.(human, breakage, ref), where breakage is(major, minor, other).Epic bikeshedding, though, either way. ¯(ツ)/¯ It's all irrelevant unless We collectively could talk Them collectively into actually changing SemVer; and not to be a pessimist or anything, but I think it's pretty unlikely. /=
@Abdillah commented on GitHub (Jul 28, 2015):
I do feel we couldn't add human versioning in SemVer standard without clear reason. I mean
major.minor.patchalready have clear specification of incrementation rule. If we proposegenerationorhumanpart, this one should have clear rule and usecase. Without those, it will clearly be repelled by SemVer people.I do propose one usecase:
Management or maintainer change
When a project changed it's maintainer and/or management due to the decisions mostly differ. Keeping it's name is a great advantage as so the current users still confortable in upgrading (they would need to notice API breaks, of course), outside the fact that the software has been changed extensively.
Personally, as a software user, I often feel suffix in the name notating generation (e.g.
ayayware4) is an ugly approach and usually keeping me from upgrade.Happy to hear others idea.
@mk-pmb commented on GitHub (Nov 5, 2016):
What if the maintainer feels they have learned so much since the last release, their view on their project has thus evolved a large step, and they no longer feel like the n00b they were at that time? First random example of what else I'd consider equivalent.
I actually like generation suffixes in the package name since that way I can, even with node.js and npm, cherry-pick some portions of a new generation of a package and still use the old generation in the old parts of my code. If the name stays the same with a generation bump, I'd have to make a proxy package that aliases the old (or new) generation, I'd have to invent a name for that proxy package, and the most straight-forward approach is… your package with a generation suffix, just uploaded by someone else and with added overhead for the alias. Let's hope the package manager will be smart about the resulting dependency graph.
@ELLIOTTCABLE commented on GitHub (Dec 14, 2016):
Nearly a year and a half later, I'd like to point out that
2-1.0.4-pre.1(i.e. “generation-semver-patch”) covers all of the above concerns, from the entire thread; makes a hell of a lot of sense; and doesn't directly require support from the SemVer folks to implement. Call it SemVer+ or something.¯\_(ツ)_/¯Just start implementing that in your projects, IMO. We're stuck with npm working the way it currently does for the indefinite future; but that doesn't mean New Things™ need to repeat those same mistakes.
@HughxDev commented on GitHub (Feb 19, 2017):
@ELLIOTTCABLE I agree and will start doing this myself. But previously you called it “human, breakage, ref” and now you’re calling it “generation, semver, patch”. I understand “human” and “generation” to be synonyms; same with “breakage” and “semver”, but “ref” and “patch” seem like different things. Should the last part be:
A.) a “reference”, i.e. a release name that does not modify the meaning of the numbers (like, say,
ubuntu 17.04-0.0.0-zestyzapus),B.) a pre-release name that does modify the meaning of the numbers (
-alphaor-rc1),C.) a patch identifier (
-xyzhotfix), orD.) any of the above?
@ELLIOTTCABLE commented on GitHub (Apr 9, 2017):
@hguiney I would love to programmatically consider it ‘opaque,’ just like the human “generation” chunk: foreshortened-git-SHA1, or patch-name, or
-alpha, or other generic use. Problem is, semver already defines actual meaningful semantics (see items 9, 10, and 11 from the spec) for the hyphenated post-patch text. A “Post-SemVer” system could either pass the lateral information through to the SemVer parser, or it could basically completely discard items 9 and 10 from the semver spec, “passing” only the contents between the hyphens through to the SemVer semantics, and leaving the final chunk for human-use. (This is what I'd prefer: besides the ‘breaking change’ information communicated with SemVer, I don't think SemVer strings communicate further useful information; and constraining or trying to overlay them with meaning is a mistake … but that's just my opinion.)tl;dr: It should be either (and I'm leaving the decision up to someone who isn't me)
… but not both.
On a separate note, I'd like to posit that ‘generation’ should be a single, monotonically-increasing, whole number. Personally, I'm very opinionated that one cannot reliably communicate meaningful information about breakage in a limited number of sections (hence, partially, why SemVer bothers me); and thus having separate ‘bits’ like that at all seems like a waste. That said, and being aware that that's a controversial view … it feels non-controversial that there only needs to be one generation section? Arguments?
@mk-pmb commented on GitHub (Apr 10, 2017):
It helps the immediate problem. When thinking a bit longer ahead, future software archeologists might actually prefer some more expressive scheme to avoid having too-huge integers. We could use a triplet (aeon,dynasty,generation) instead.
To avoid a left-side generation notation be confused with the traditional semver triplet, thus degrading the latter to a pre-release version, we could use roman numerals separated by hyphens or colons.
@chindraba-work commented on GitHub (Mar 21, 2019):
@bperrybap You said:
You cannot have a post-release which is not a pre-release. It might become a never-released, but that is not the problem. The problem is in the "view" the developer takes. There is no lack of support for development versions. There is a lack of under standing about the SymVer spec. I've addressed that on another issue, and won't repeat all that here. The upshot of that is you create the branch for the development. Tag that brach with the appropriate version number (the next patch-level version plus the pre-release version string). You then do your development on that branch.
Now you can generate SemVer compliant strings, with as much detail as needed. For example you can use, in Linux,
semver_version="$(git describe)-$USER-$(date --utc +%Y%m%dT%H%M%SZ)", which, on the branch taggedv3.2.4-devcould generate something likev3.2.4-dev-16-gd3a71de-bperrybap-20190321T063730Z. When merged into master, the new tag might be v3.2.4, or v3.3.0, or even v4.0.0, but until merged it remains v3.2.4-dev-something. And the something is both human-readable, giving the user and the timestamp, and machine-readable, giving the commitish which is trivial to parse, or even regex.There is no ambiguity as to where the development branched from, or that it is a development branch. It does require that devs stop calling it a post-release, using pre-release instead. Post-release programming servers no purpose. Why would I want to do more coding after it has been released?
Lastly, if there has been such a fundamental shift in the project that it MUST be differentiated from all prior versions, then it deserves a new name. Either a numerical designation, such as GnuPG gpg vs gpg2, or a totally new name, such as GAPS v6.0.0 being rebranded as GNSS Analysis and Positioning Software. Conversely, if the project has undergone a complete rewrite, including a language change from Perl to Python, yet the API remains unchanged, it deserves no more than a patch-level increase. Not as good for the ego as a major bump, but more honest to end users. Afterall, what would be written in the changelog? "Re coded from Perl to Python". Nothing says you couldn't change the minor, or major, versions. Why would you though? To satisfy the ego(s) involved? Now all the users think they need to read the changelog and plan for the sweeping changes in their code. They put off the "update" until they have the time to spare for some major testing and revision on their own code base. Wasted worry and time since there is nothing they need to do at all, nothing in the API contract changed!
@bperrybap commented on GitHub (Mar 21, 2019):
@chindraba-work
Your example actually demonstrates the problem I wrote about.
It seems to violate rule 9.
In your example the released code was v3.2.4 and then development proceeded with development releases before any known next release version number is known.
Yes new "semver" versions can be created using a dash along with git describe information to designate the development version information but according to rule 9 the dash indicates a "pre-release" version.
From reading rule 9 it would seem to indicate that a release version using a dash precedes (happens in time prior to ) the version number not a release that can be post (occurs in time after) the release version number.
In my own development I do use an automated versioning mechanism similar to what you describe for development only releases that occur after an "official" release. While it seems to violate rule 9, I find it useful in that these development releases will according to rule 9 have a lower precedence than the last "official" release that they are based on which works for me, but others may want a different behavior.
Perhaps, it may come down what "pre-release" means in the context of Semver and rule 9.
If "pre-release" does not refer or imply to when in time the release is done but rather that the version is a developmental or experimental release of a lower precedence, then I think many people could use the mechanism for both pre and post releases by overloading they favorite specific information in pre-release fields and metadata fields.
But as written, the semver spec does not seem to describe this type of post release version usage.
@chindraba-work commented on GitHub (Mar 21, 2019):
@bperrybap Why would anyone want to do more code work after a version is released? What is the purpose of any post-release version? I can think of no reason to create a post-release version, of anything.
If, however, the purpose is to add features, or do any kind of change - with the intention of releasing those changes later, then the work is being done on a pre-release. Section 9 specifically states that such a release may not satisfy the intended compatibility requirements as denoted by its associated normal version.
If the "post-release" version is done for future release, then it is a "pre-release" of the next version.
@lolmaus commented on GitHub (Mar 21, 2019):
This is exactly why I created this issue. I do not want to rename my project because it reached a large milestone (generation). I want to have a version number that denotes generation.
Note that numerous projects violate SemVer because their owners want the major version number to indicate a generation and not skyrocket.
Take for example the AngularJS project. They decided to rewrite it from scratch and start following SemVer strictly. The new generation is called Angular. The similarity of the name creates a lot, A LOT of confusion.
Now we have AngularJS 1.7.8 and Angular 8.0.0-beta.3.
Instead we could have AngularJS versions 1-1.7.8 and 2-8.0.0-beta.3. This notation may seem weird due to strong habbit formed to classic SemVer. But it you think about it, it makes a lot of sense.
@eps1lon commented on GitHub (Mar 21, 2019):
Same problem with TypeScript:
-- https://github.com/Microsoft/TypeScript/issues/14116#issuecomment-280592571
@chindraba-work commented on GitHub (Mar 21, 2019):
@lolmaus That is the difference between "Semantic" versioning and marketing/ego versioning. Software engineers and developers ought to prefer "truth in advertising" more than advertisers do. As a developer I do not care about what changes you have made "under the hood" I just need to know if you have moved the brake petal. Or, if all else fails, I need to know that I cannot trust your versions to really "mean" anything. The purpose of SemVer is "meaning" and the focus is on the meaning that other developers, or users, need to know.
@lolmaus commented on GitHub (Mar 21, 2019):
@chindraba-work, my suggestion allows to get the best of both worlds: let humans see the generation of the app which is most meaningful to them (am I really an egoist to desire that?) without sacrificing any technical details that you point out.
But it seems that you're arguing not against my suggestion (a fourth digit for generation), but instead against non-semantic versioning, which is not the topic of this thread.
As for the ego thing, I'd rather say that it's the SemVer advocates who have ego problems:
Rejecting the suggestion because SemVer works fine for projects who use it as intended -- is like refusing to install wheelchair ramps on buses because buses work fine for people who are able to board them.
@mk-pmb commented on GitHub (Mar 21, 2019):
OTOH it's much easier to fork a humanver than set up an alternate, improved fleet of buses. The harder part would be convinving
people to switchauthors of semver support libraries/tools to also support humanver. It's like people getting annoyed by how long the ramp procedure takes when all they care about is getting to $dest on time.@FichteFoll commented on GitHub (Mar 21, 2019):
That's because Angular and AngularJS are fundamentally different projects. It wouldn't even make sense to release the successor under the same name (but with a different "generation" identifier) because that would create even more confusion. (Remember that this actually happened.)
I don't see how this (particular example) falls into SemVer's scope.
@lolmaus commented on GitHub (Mar 21, 2019):
Every time I rewrite something from scratch I have to rename it?
Angular/AngularJS is an extreme and rare example. I assume it is much more common that a complete rewrite happens in the same repo, with the same issue queue and same project website.
Like we don't have a separate repo/issue queue/website for Apache 1, for example. Or Opera Presto.
The concept of individual names is more common for old model of software distribution where you make one huge release per year (or more) and ship it in physical box.
In the modern world of cloud computing, SaaS and app stores, this no longer makes sense. You do NOT want to register a new application to an app store after rewriting the existing one. Because existing users will not see it! You want it to be the same app, under the same id (name), updating transparently from old version.
But at the same time you want your users to see that its a huge release and not another one of dozens of breaking changes irrelevant to most users!
@bperrybap commented on GitHub (Mar 21, 2019):
@lolmaus
I couldn't agree more.
@chindraba-work
Uh... Because the project is still active and the most recent release is not the last release.
There are many reasons do experimental internal development releases that are post release that are done before the next release version is known.
Experimental bug fixes, or even rapid prototyping.
EXACTLY. But at the time of creating the "post-release" version(s) the version number of the next release may not be known yet and SemVer seems to assume that the next release number is always known, which implies that the extent of the compatibility of all the s/w in the next release is also known.
Consider the real world case of trying to fix an issue. How extensive the issue is is not yet fully known so it is unknown yet how extensive the modifications to the code will be which means it is unknown how a fix may affect existing interfaces and compatibility, which means you can't yet pick the next SemVer version yet.
There are many cases where rapid prototyping of experimental fixes are used as part of debugging leading up to a final/official release. And while those internal releases will likely never see the light of day outside of development, there are cases where there still needs to be a release version number/string assigned to these types of releases and SemVer does seem to be able to handle it.
Given the attitude and inflexibility of those that control SemVer, I've given up on ever trying to get SemVer tweaked to allow it to be more compatible with many pre-existing development / release / versioning methodologies already and currently being used on many projects / products.
Now, whenever I am forced to use SemVer compliant version strings I simply abuse the version string format to contain the information I want/need to be able to get things done without having to modify SemVer to allow/support such information. The version strings are still fully compatible/compliant with SemVer version strings but I simply abuse the "pre-release" and "meta-data" fields using the "-" and "+" characters and strings to convey the additional needed information to allow pre and post release versioning.
@lolmaus you may want to also consider doing something similar. Perhaps you could simply abuse the various "pre-release" and "meta-data" fields to provide/include the project generation information you want/need while still getting the results you need from the existing SemVer precedence rules.
i.e. abuse the version string with your added version information in away that tricks the existing SemVer precedence rules to work the way you need them to work with your abused version strings. (this is what I do)
In other words, give up on trying to get SemVer tweaked/updated for better functionality and simply figure out a way to abuse it to allow you do what you want to do.
@chindraba-work commented on GitHub (Mar 21, 2019):
@lolmaus That is the difference between "Semantic" versioning and marketing/ego versioning. Software engineers and developers ought to prefer "truth in advertising" more than advertisers do. As a developer I do not care about what changes you have made "under the hood" I just need to know if you have moved the brake petal. Or, if all else fails, I need to know that I cannot trust your versions to really "mean" anything. The purpose of SemVer is "meaning" and the focus is on the meaning that other developers, or users, need to know. For each commit, issue the command
git tag -a "$(git describe)-$USER-$(date --utc +%Y%m%dT%H%M%SZ)"If that's not simple enough, I presume a script could be written to apply the commit, the tag, any message gpg signature and sign-off required in one simple command. No two versions of the code will have the same version number - ever, it will always be SemVer compliant.@mk-pmb commented on GitHub (Mar 22, 2019):
As far as I understood the opening post, it wasn't about how to achieve compliance with the existing semver, but about making it carry additional useful, meaningful information.
Windows NT 5.0 and Windows NT 5.1 are good examples of how a technically useful version descriptor will relate to an end-user-useful version descriptor if the former isn't capable of assimilating the latter. (Spoiler: Wikipedia will pick the latter as the headword.)
Edit 4: Historians will be fine though. They're probably quite used to dealing with dumb decisions made by people who didn't know better at that time. They'll manage to cope with Windows 3.1 < 95 < 7 and Office 2003 < 365.
@chindraba-work commented on GitHub (Mar 22, 2019):
@mk-pmb You are correct. I got sidetracked into the other issue. WRT extra info I'm back to the basics of "not needed". The information potentially carried by the extra digit, or whatever, is irrelevant to the data included in SemVer. Marketing dept's "version" (Win XP, Win Vista) need not have any correlation numerically with the program's "version" string (Win NT 5.1.2600, Win NT 6.0.6000). The information included in the design of SemVer relates to how the API for the listed version of the code will relate to the API of former (future) versions of the same code. The communication is between the creator of the code and the user of the code, hopefully done at least semi-automatically.
If my code is for a module which your code relies upon to perform some function, you, and your code-base, need to know when I've made changes which could affect how you connect to my code. Maybe it breaks something, maybe it don't. That depends on what change caused me to bump the major-level. Maybe it now provides something more useful, without changing anything it used to do, and maybe - as far as your code's operation is concerned nothing has changed. SemVer tells you all that in a moment's glance, and your code, or code manager, can detect changes that might require your intervention. If the only change is that I've completely converted by Bash script to a C++ module, with the API remaining identical in specs, that's only a patch-level bump (even for 3-month's work).
If I want accolades for doing the switch I can call it new and improved, or any other marketing phrase I choose. As long as I follow the 3-level spec for SemVer your program can determine when, and if, it's affected without you having to read my 1200 word marketing hype on the fancy new website.
Even though Microsoft does not follow SemVer, their "real" version numbers meet the same spirit. What the name on the box says can be unrelated to that number, or to reality for that matter.
As to the end user (where the program is user accessible) the Windows example is a perfect example of "worthless". Without the out-of-band information how would anyone know whether Win XP is newer or older than Win ME, or Win Vista? Those "versions" convey informational content of zero. Office 2000, Office 2010, Office 2013 gives me "some" indication of ranking, without telling me if my Excel files from one will work in the other. From reading sales material or wiki pages, and other sources, I can figure out what works, what breaks, and what changes, but the "version", sans other data, give me no clue. Unfortunately, any other "version" can carry a similar load of possibly useless data. Only if I know how and why the project changes their numbers can I infer data from that version number. SemVer creates a standard which the developers claim they will adhere to, and allows me to presume to know what their increased version number means. When my project has multiple dependencies, to multiple layers, a verified chain of SemVer data can reduce my workload considerably. A collection of meaningless names and random numbers is less than helpful, it creates even more work than a set of at least incremental numbers.
@mk-pmb commented on GitHub (Mar 23, 2019):
Thinking about it again, I discovered I can make the scheme of my "marketing" version assimilate the semver, then my end users will still have just one thing they'll consider is the version.
I had hoped making the generation number part of semver would help convince tool authors to support it in their sorting or whatever tools, but argument by authority could just as well backfire in losing that authority. There's also a chance we get all the design by committee pitfalls. It's useful to have standards be stable after all.
@lolmaus, maybe you can open a repo for developing an embrace-and-extend fork of semver, where people inclined can discuss all the pros and cons and hows, and once it's a convincing draft, people will start to use and support it.
@chindraba-work commented on GitHub (Mar 23, 2019):
@mk-pmb Creating a Next Generation embrace-and-extend fork of semver would fit very nicely, I think, with the comment by @ELLIOTTCABLE above. Provides functionality, or information, not in SemVer that others may desire to have. Others being consumer or producer, or both. At the same time it neither breaks, nor replaces SemVer for those who need it. Similar to how GUI can inter-operate with CLI. Neither is the answer, and both serve mostly common goals with their own unique goals served as well.
@ELLIOTTCABLE commented on GitHub (Mar 23, 2019):
@chindraba-work Feel free to take my idea and run with it! I like @mk-pmb's naming of
humanver, too.Also note that this idea, almost identically, parallel-evolved a year later in the linked thread, Microsoft/TypeScript#14116. (see here.) @niieani usefully notes that the initial ‘human’ field need only be presented to humans — machine systems can, and should, drop the metadata.
I'd take that a step further, and inherit all of npm's version-comparison operators, and simply allow them to ‘fall through’ to the initial breakage-counter:
~2-1.2.3 := >=1.2.3 <1.3.0,^2-1.2.3 := >=1.2.3 <2.0.0, etc. Explicitly disallow any machine-logic on the humanistic name-portion; because predicating version dependencies on whether the package is named “flib” or “flob” is patently ridiculous; and the ‘generation’ field is intended to be a more-convenient, less-hacky way of incrementing the name. (That also enforces simultaneously, and honestly, monotonically incrementing the breaking version.)@chindraba-work commented on GitHub (Mar 23, 2019):
@ELLIOTTCABLE I'm not the one, or in the team, to develop
humanver, or whatever. I appreciate the concept to Explicitly disallow any machine-logic on the humanistic name-portion, and the reasoning behind that seems sound as well.I don't think SemVer is a requirement for user-facing projects. The purpose of SemVer is inter-component checking, not informing users when the interface or work-flow has changed on what they use. There are things, such as Bash in Linux, where the project is both component and user-facing, and for those SemVer is appropriate.
Another thing often ignored, it seems, is that SemVer is not the version system to replace all others. A project should only be required to use, and adhere to, SemVer if it is in an ecosystem that specifies such as a rule. From scattered comments I think that is the case for
npm, but I know of no other. The more projects which follow SemVer the easier it becomes for other developers to build dependable systems.My biggest concern is that if a project claims SemVer, it should be compliant with SemVer specs. TypeScript does not claim SemVer, even though many developers would like them to. As I understand SemVer, the classification of every release as a breaking release because of the potenial for bugs to "break" the system, as used in the TypeScript thread you linked, is wrong. Changes in the API drive the version numbers, not failures to implement it, or corrections of such failure.
@claell commented on GitHub (Sep 13, 2019):
I don't know whether this is a duplicate of #191 but at least these issues are related pretty much.
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Thanks everyone for contributions, you're amazing 🎆 Did you find any consensus?
@mk-pmb commented on GitHub (Jun 10, 2020):
I can't see consensus so far. My stance is that the "generation number" is out of project scope and should be addressed by another project.
@tsjensen commented on GitHub (Sep 24, 2020):
My feeling is that the "generation" would be mostly marketing. As a developer, I care if my build might break after an update. If so, I may have to look a bit closer and be prepared for trouble. Even if it was "just" the order of some arguments.
@lolmaus commented on GitHub (Sep 24, 2020):
It's not just marketing. Semver requires bumping a major version number for any breaking change, however small. A major version bump gives you no idea about to what extent the app/libarary has changed. It could be an itsy-bitsy change that you will never notice or it could be an entirely new API.
A bump of the generation version number can indicate:
The generation number is informative for library developers and consumers.
Currently I'm using branch names like
gen-4to indicate the generation. Not every major version bump requires a generation bump. As a result, SemVer version numbers are out of sync with generation numbers.By looking at a SemVer number, you have no way to tell which generation this verison belongs to (and which set of APIs it supports, for example).
This is annoying and disappointing. I see no practical reason why this should be the case, other than the inertia of the community and SemVer maintainers. 😒
Note that the alternative of moving the generation number into the project name is not really an option:
AngularandAngularJS, which is the recent one? If you're not in the know already, you'll have to google it to find out. And some people wouldn't even realize those are two incompatible libraries. 👎@tsjensen commented on GitHub (Sep 24, 2020):
There is no such thing as a "small breaking change".
I've had stuff fail because someone changed one letter in a method name from lower-case to upper-case.
Update: There is also no such thing as a small "amount of breaking changes between versions".
@ljharb commented on GitHub (Sep 24, 2020):
There are certainly degrees of breakage, but these are impossible to quantify generically.
@claell commented on GitHub (Sep 25, 2020):
This is pretty obviously not what @lolmaus meant. Small was most likely not referring to the impact of the breakage, but to the amount of breaking changes between versions.
@mk-pmb commented on GitHub (Sep 25, 2020):
I understood it to mean that even a small amount of effort theoretically required to fix stuff, does need developer attention, maybe even code review and tests, and thus other procedures than a straight upgrade. We could think of even more complicated scenarios with code signing, important people being on vacation, unpredicted high number of bus accidents, etc. In summary, people who don't work on project P can't reliably predict the impact a breaking change will have on project P, and should thus assume the worst case. However, if any breaking change leads to the worst case assumption, then there is no useful measure for "big" or "small" breaking changes.
@claell commented on GitHub (Sep 27, 2020):
The discussion here is not about whether to indicate breaking changes, but to indicate large refactoring for example or other stuff (see initial description). Thus it is not really relevant to that discussion that of course every breaking change is important and should be indicated. This is about how to indicate larger refactoring etc. so users can easily recognize that.
@ljharb commented on GitHub (Sep 27, 2020):
You indicate that with documentation, with prose. Just because there's a version number doesn't mean every possible semantic needs to be shoved into it.
@lolmaus commented on GitHub (Sep 27, 2020):
@ljharb Your rhethoric works both ways. 😕
@klehelley commented on GitHub (Sep 28, 2020):
While @ljharb's rhethoric works both ways, I tend for the moment to be on his side of the argument, though some of your arguments make sense (see below).
Sure, SemVer as it stands will not cover all cases, and it is understandable that there are a lot of cases that deserve a proper discussion and evaluation. However making the versioning scheme more complex means that it will be less easy to reason about. There is some balance to find. I think this balance -- and the reason why some changes are (un)likely to be done -- could be better understood by most people if the projects's goals and non-goals are clearly laid out.
I think as far as goals go, the "Introduction" part of the specification makes a pretty good job. Its main goal is to make sure consumers of the "public API" being versioned know whether they can expect an impact when they upgrade from a version to another. Clear non-goals, if any can be defined with a clear consensus, would definitely help people know whether the needs they have and change they envision are likely to be welcomed with open arms or will require very strong arguments and no guarantee that it will ever be taken in consideration.
As it is, SemVer is somewhat brunt in that there are very clear differences between what an upgrade of MAJOR, MINOR or PATCH means. It does make the job of the producers of the "public API" not too hard, as answering the question "Is it a breaking change? Was anything added?" should not be too hard. To the point that there are tools to help automate that decision.
A project using SemVer generally upgrade its version string by following objective reasons. I feel that the fourth number proposed would be upgraded for subjective reasons. Taking the examples listed in a previous comment:
@ljharb commented on GitHub (Sep 28, 2020):
Support is a time commitment that changes over time as life happens - the breakingness of a project does not change over time. The version number simply can’t promise any level of support, ever, because it can’t guarantee it.
@lolmaus commented on GitHub (Sep 28, 2020):
@klehelley Thank you so much for an explicit reply and for actually looking at the matter from my point of view. 🙏
Ah, finally some common ground! 😌 Previously, the argument felt like an argument between atheists and believers. 😅
Well, as a project owner you don't owe us anything. You could say "my goals are my goals, I didn't force you to adopt SemVer, you are free not to use it".
But in practice SemVer has become an industry standard, with infrastructural tools supporting SemVer and only SemVer. Starting a competing standard will not solve anything, only make everyone's life worse (obligatory XKCD reference).
Thus, I believe SemVer maintainers should feel some sort of responsibility in towards the developer community. As for developers, we have no real alternative but to share our pain points in
semver/semver/issues.Saying "if it works, do not touch it" is surely one way of dealing with such concerns. But it's not that far from stagnation.
Well, neither SemVer can guarantee lack of breaking changes. Because any patchy change can bring bugs and regressions which can break your app. And as we know, there is no such thing as a small breaking change.
(Yes, there are test suites to detect regressions, but test suites are equally helpful to detect breaking changes.)
Not to mention that the most libraries do not consider upgrading non-SemVer dependencies as a breaking change. And don't forget trivial human factor.
As a result, in practice developers can not rely on SemVer as much as you want it to seem.
Please note that I'm NOT trying to slander SemVer: an imperfect result is infinitely better than no result.
My point is that it's a tiny bit hypocritical to criticize this proposal with full strictness while being indulgent to current state of affairs, treating SemVer as if it is operating in a perfect world with no bugs, non-SemVer dependencies and human factor. If you were less strict to the proposal and more realistic about actual SemVer impact, you'd find that the promises this proposal makes do not exceed what promises SemVer makes in practice, and is not substantially more subjective.
As for the new version number being more difficult to understand, it is not a deal-breaking problem but rather an exciting challenge to find a solution for.
In order to differentiate the "subjective" generation from the "objective" triplet, I can think of doing this:
1|2.3.4-beta.0. Or evenjj-abrams|2.3.4-beta.0, if we take the subjective part seriously.You can not confuse the new segment for a major version, and it provides a wonderful opportunity to reset the triplet numbering should the maintainer need it, allowing for effortless maintenance of parallel branches.
@ghost commented on GitHub (Oct 25, 2020):
Wouldn't that make the MINOR version number irrelevant?
I don't think SemVer needs such a big change. If you're advocating for developers, I think they have a hard enough time caring about following the strictness of SemVer as-is. Adding a generation number, which after what I read, just adds more insanity.
The current specification provides quite a bit of flexibility. For instance, you could just define your own semantic build identifier:
1.0.0+1or1.0.0+fooor1.0.0+foo1, where foo is something that's not foo.@lolmaus commented on GitHub (Oct 25, 2020):
Yeah, it would be much easier if SemVer didn't fail in almost every projects due to inevitable factors::
I think it's time to admit that SemVer just does not work in real life. It makes guarantees that can only work in a 100% formal system, and software development is not nearly as formal in practice.
BTW, you have implicitly admitted that using SemVer is already insane. 😬
How do you handle the following case with SemVer:
3.4.5→4.0.0.3.7.8and4.5.6.5.x,6.x.Questions:
@mk-pmb commented on GitHub (Oct 25, 2020):
How about adding the generation number at the end, separated by
+gen?@ghost commented on GitHub (Oct 25, 2020):
@lolmaus If you're introducing that many breaking changes that quickly, then there are deeper issues that need to be addressed than using SemVer. Developers can't just release breaking changes into the wild willy-nilly. I think that's what pre-releases were designed for.
I don't understand how you're advocating for an additional component (i.e., the introduction of the generation number), while at the same time saying that software development isn't as formal in practice.
@mk-pmb That's an excellent idea, and exactly what I was trying to suggest.
@mk-pmb commented on GitHub (Oct 25, 2020):
@lolmaus, maybe we can adapt-down to major numbers, your approach to handle a new generation number introducing the breaking change (because you might have been too optimistic to make a pre-release), and while you continue to fix the previous generation, you come up with another feature that's worthy of a generation number bump. How would you solve that?
@lolmaus commented on GitHub (Oct 25, 2020):
1.0.0+fooand1.0.0+bardon't seem much different, but the point of the generation segment is to identify those two versions come from independent development efforts within the same project.The hierarchy should be like this:
And not like this:
Every mature project has many problems. If SemVer can't handle that, it means that it's designed for an ideal world and not suitable for real life cases.
Moving the fault from the spec to the developers is easy but not helpful.
@bromps So do you admit that SemVer cannot handle this case: infrequent, but surely not uncommon?
And what if you introduce a breaking change between prereleases?
Say, somebody is already using
2.0.0-rc.2because it finally fixes long-standing issues and is stable enough. How do I indicate that it's safe to upgrade to2.0.0-rc.3but2.0.0-rc.4is breaking (e. g. because bumps a major version of a subdependency)?I anticipate that you say that pre-releases are intended to be short and quick. But again, various difficult situations happen in real life. If you've never been stuck in a pre-release stage, then consider yourself lucky.
But does this mean that SemVer is only aimed at lucky developers? And when you run into a situation that SemVer cannot handle then it's your fault for not knowing you're unlucky. You're simply not its target audience! When it happens, should you stop using SemVer in your project? Or should you abandon development and try yourself in bicycle repair or something. Or should SemVer maybe crawl out of eight year stagnation and resolve some of its issues?
PS My suggestion of the generation/branch segment does not solve the breaking prerelease problem. I'm mentioning it to prove that SemVer has long-standing issues that its owners should stop turning a blind eye on.
My goal is to make SemVer more flexible, give the developer more control, let them use their judgement instead of submitting to a formal, idealistic spec which is blind to real life problems.
Simply let a developer indicate a generation/branch that this version belongs to and suddenly there is much less frustration:
@mk-pmb Sorry, I did not understand the question.
@mk-pmb commented on GitHub (Oct 25, 2020):
@lolmaus I meant to point out that the conflict of non-linearity that you described can happen at any level in the number hierarchy, so a generation number won't fix it. Of if you knew a fix, then it could probably be applied to major versions as well, and wouldn't need a generation number.
@mk-pmb commented on GitHub (Oct 25, 2020):
I for one think that might be a good idea. If your project runs into those kinds of problems, it's probably so enterprise-ready that consumers won't benefit from using semver anyways.
@lolmaus commented on GitHub (Oct 25, 2020):
OK, I seem to have already acknowledged that talking about prereleases.
The generation segment covers a case when you make a deliberate decision to maintain two branches in parallel. It indeed does not provide an ad-hoc fix to every case.
What's your point? That only silver bullet, catch-all solutions are worth implementing? And a specific solution to a specific problem should be discarded because it does not attempt to fix other problems?
How?? Most if not all package managers support semver and only semver.
This is what npm says:
So if I do my
foo|1.2.3thing I will not be able to share my library with the community. I will not even be able to use it privately for myself.It's not only a matter of lack of alternatives. SemVer dominates development to a point it is impossible not to use it! If that is not a reason for SemVer owners to exert some responsibility towards the whole development community, then this thread is indeed in vain.
@ghost commented on GitHub (Oct 25, 2020):
@lolmaus I understand that you're passionate about SemVer and the issues surrounding it. Don't get me wrong; I don't think it's perfect. However, I don't see a good way for the SemVer software ecosystem to conform to the new generation you are proposing.
No.
Pre-releases are still unstable. I've used and maintained pre-releases. I've never run into problems with users complaining about broken functionality since everyone was on the same page that the software is still unstable.
The whole technology industry is moving away from the idea of giving developers more control by writing more-opinionated frameworks and creating more layers of abstraction.
The flexibility you are proposing, semantically speaking, already exists.
You can do this with a Git branching strategy and keep SemVer intact.
Given I have version 1.0.0 and then upgrade to 2.0.0, but still need to support 1.x, then I can have a branching strategy like this:
That's a straightforward representation, but you get the idea. Parallel major versions can be maintained in parallel and integrated into the main branch throughout their lifecycle. This is commonly done today with Node.js and NPM, I believe.
@mk-pmb commented on GitHub (Oct 25, 2020):
So now the argument is about tooling again. As earlier above in the humanver discussion, I believe it would be a bad idea for SemVer to introduce changes that will cause version parsing errors in unmaintained tools. Considering the wide adoption, it's inevitable that there are lots of projects that cannot reasonably be updated. So the better choice is to try and win the hearts and minds of those developers who -can- update their version parser, to support humanver alongside semver.
Once humanver is somewhat stable, we could consider adding a promo like "Tools SHOULD also support humanver".
@lolmaus commented on GitHub (Oct 25, 2020):
Your suggestion does not explain how to solve the problem. What exactly do you do when a release in the legacy branch contains a breaking change?
Can't argue with that, but it's totally SemVer's fault for not providing any means for future upgrades (reserved delimiters or something) and as a result falling into stagnation and dragging the whole development community with it. ☹
And now you use this as an argument not to evolve. Okay... 🤷♂️
That's not feasible.
@mk-pmb commented on GitHub (Oct 25, 2020):
Agreed. That's a tragedy common to a lot of technologies that got widespread adoption because at the time it was the best that humankind could agree on. It's a pity that VHS wasn't specified with an upgrade path to Betamax.
I hold the community accountable for this. They should have chosen more wisely back then. Damn all those fools that fell for VHS. They got what they deserved. Why do humans never learn from history.
@mk-pmb commented on GitHub (Oct 25, 2020):
If it's impossible to get tool maintainers to embrace the new version syntax, then it doesn't matter whether its name is SemVer or HumanVer, and a breaking change to SemVer will just muddy the meaning of that name, making people become annoyed by the fact that the name doesn't hold up to what they thought it meant.
@ghost commented on GitHub (Oct 25, 2020):
By that point, the two pieces of software have diverged so much that it only makes sense to create a whole new project for the newer version of software. If you're introducing that many major breaking changes where your users can't possibly keep up, you're doing something wrong. Earlier you said something like "it's easy to put the onus on the developers," but by that same token, they have to take responsibility for their decisions instead of blaming everything on a tool or framework.
SemVer isn't actually that strict. There's not that many rules to conform to. All you need is a public API and a moderate understanding of how to bump each version with the changes you make, and then communicate that to your team and other contributors.
@lolmaus commented on GitHub (Oct 25, 2020):
I love analogies, but that one just doesn't work. There is no way VHS and Betamax could be compatible, they are different in too many ways.
But we can compare them. Betamax could only record one hour of content, and they could not increase it because the cassette did not have extra space. Eventually they made it up to 2 hours by reducing the quality of the recording, but that didn't matter because by then they had lost already. One hour just wasn't enough.
VHS started at 2 hours, allowing to record a feature film or a sports match, and could be upped to 3 hours without reducing the quality.
Another good analogy is how a DVD is not limited to a number of languages it supports in audio tracks and subtitles, and how its menus can be configured flexibly.
It's always my fault, I got it already. I am not capable of writing bugless code — my fault. My dependencies use subdependencies that violate SemVer — my fault. I did not anticipate SemVer stagnating when I was starting my career — my fault.
Nope.
SemVer is a monopoly. For SemVer it is relatively trivial to introduce the generation segment:
node-semver).Convincing everyone to migrate to a different system is not realistic. The community is way too inert and biased toward SemVer for that.
Firstly, the severity of the breaking change is not that bad. If your app is using a lockfile (it really should), then the introduction of the generation segment will not break it. Your CI will keep working as usual because all your dependencies are locked at the old format.
And if you're upgrading your dependencing, which might introduce the new format, you can as well upgrade the package manager.
Secondly, you're making a substitution here. The suggested fourth segment is perfectly semantic. It carries specific meaning.
"Semantic" does not mean "never having any breaking changes". In fact, it have had a breaking change around 2012 (that's ironic because projects that strictly follow SemVer have their major number skyrocket).
Or do you read "SemVer" as "StagnVer"?
No and no.
They have not diverged "so much" and it's not practical to start a new codebase.
Here's one real-life scenario (that I've seen many examples of) to illustrate. You're maintaining an addon for a framework. Eventually the framework gets a major verison bump, shedding off a whole lot of deprecated APIs. Naturally, your addon needs to conform and you release a new major version compatible with the new version of the framework. Your addon keeps evolving, and its major version number keeps growing. That's just how SemVer is.
But there are thousands of users who are stuck with the old version of the framework. Their apps are using dozens of addons, many of which are long unmaintained. It takes users many months to upgrade their apps to the new framework version. Sometimes, the upgrade is so hard that it's not commercially reasonable, but the app still needs to be maintained for security patches and even new features. This is real life, not some idealistic bee ass.
Thus, there is a huge demand for the old version of your addon to be maintained. A few months into the release, the old version is still more popular than the new. And users still need new features.
Starting a second repo is a bad idea because:
AngularandAngularJS: which is more recent one?)But of course, to SemVer advocates, this whole thing is the library maintainer's fault and the users' fault. It's not SemVer's fault for being an inadequate solution under real-life challenges (it is).
PS That was just one example. I'm sure there are many, many more cases where the generation segment would make total sense and resolve lots of frustration both to users and library maintainers.
Oh yeah, Ive also just randomly read the first requirement of SemVer:
It's funny how over 50% of packages that claim to support SemVer — violate it by not explicitly defining the boundaries of the public API.
For example, my weapon of choice, the EmberJS framework, formally supports SemVer. It only makes breaking changes on major version bumps and it has very extensive and elaborate API documentation. But every other minor version upgrade has been a PITA in most of my apps. They were breaking in more than one way at once. The reasons for that are:
Of course, all this results in that framework upgades are extremely brittle. SemVer no longer means s@#t and can't help resolve the problem in any way. It's simply too naive to think that specifying "don't make breaking changes when you bump minor version number" will resolve those issues. That's just not how development works. Development is not a purely formal, determenistic process.
And please don't say "you're doing it wrong". You can say this about me but not about EmberJS developers. With AngularJS having been restarted from scratch as Angular, offering no upgrade path, Ember is currently the oldest actively maintained frontend framework, and very innovative at the same time. It's competitors such as Angular and Vue are actively borrowing from it. Ember has an exceptional maintenance record, no other framework has evolved that much without abandoning their users via "it only makes sense to create a whole new project".
@tsjensen commented on GitHub (Oct 25, 2020):
I think SemVer should stay as it is.
Other versioning mechanisms exist for projects that have different requirements.
@lolmaus commented on GitHub (Oct 25, 2020):
@mk-pmb @bromps Are you familiar with the Bayes' theorem? It provides a curious explanation to why we cannot reach an agreement.
Both your and my brains are using the Bayes rule under the hood to assess the fourth segment proposal.
The difference is that for me the "prior probabilty" component of the equation is very low: I don't see SemVer as the savior, I'm seeing issues with it and I believe those issues can and should be fixed to make development less frustrating on either side of maintainer/use barricade.
You believe that SemVer is the way to go by default. SemVer is the best there is, it has no real alternatives, it has been working fine for almost a decade, and it can serve many more decades if we don't break it. That's your prior probabilty.
The problem is that when the prior probabily is close to 1, then other components of the equation stop influencing the result. However strong my arguments were, however many practical examples of SemVer failing I provided, you opinion will not change.
@lolmaus commented on GitHub (Oct 25, 2020):
@tsjensen Can you please name a few of those versioning mechanisms?
@bperrybap commented on GitHub (Oct 25, 2020):
Finally, this github issue is closed and put out of its misery.
(not that the actual issue was ever resolved)
It was pretty clear even 6 years ago that those controlling semver were close minded and were set on doing things a very specific way and were not going to budge on adding other capabilities to support slightly different methodologies even when presented with compelling evidence of certain semver missing capabilities and the need for some enhancement tweaks to support many real world development and deployment scenarios/practices.
I gave up on ever trying to get semver updated years ago,
It is and appears always will be a very rigid system that does not support many real world practices.
For when I have to use it, I now just abuse certain meta fields to do what I need.
(post release development builds before the next release number is known, being the main need)
For what it is worth, I do think the VHS vs beta comparison has some merit if you look at what happened.
In that case, Sony came out what what they perceived to be "The Best", but over time, the market decided that they wanted other capabilities and left beta behind to get it.
The same could happen with semver.
@ghost commented on GitHub (Oct 25, 2020):
Yeah, lots of emotions here. It's probably just best to create a new versioning framework that people can collaborate on and contribute to if SemVer doesn't meet your needs anymore.
@bperrybap commented on GitHub (Oct 25, 2020):
anymore?
For many, it never met their needs. and THAT was the issue.
@mk-pmb commented on GitHub (Oct 26, 2020):
Ok you got me there, VHS and Betamax probably weren't a good comparison, they had different usecases. And I should instead have used that argument of different uses cases to suggest the authors of such big frameworks like Ember or Angular should step away from trying to use SemVer. (See my comment in issue #323, "Feedback: what semver is not for (semver is not for Products)".
Without agreeing or denying your idea about Bayes and brains, I refuse the assumption that
because I see very limited use in SemVer. It's good-enough in its niche, but in no way "best", just smooth and/or lucky enough to have gained wide adoption. I even consider its lack of an easy upgrade path being one of the things that makes it too broken to be salvaged, so I resign to advocating damage control.
All of that still with huge respect for the authors and maintainers, because SemVer helped the community reach a very comfy position from which to criticize it for not being perfect. ;-) "Good enough for that special niche" saves us from enough of the pains that we can have enough energy to try and find other versioning schemes for the remaining fields.
We seem to live in different worlds.
I'm not that sure, but let's at least try to avoid it breaking.
I'll be happy to try and help with efforts to establish better versioning schemes. Let's invent the ultimate new video storage so we can leave all of VHS, Betamax and DVDs behind. Once we have them, we could even add to SemVer that compliant projects MUST justify why they still use legacy SemVer. ;-)
@lolmaus commented on GitHub (Oct 26, 2020):
They didn't. If Betamax had a legit, substantial use case other than home video, it would not die out.
Some of them don't. E. g. TypeScript is using a decimal notation, i. e.
3.9is always followed by4.0.But the problem is that all projects have no choice but to use the SemVer schema, because SemVer is a friggin' monopoly. You can't do a generation segment because your package repository will reject it.
That won't solve anything.
Only SemVer is in the position of fixing the issue. Firstly, because it's a monopoly. Secondly, because this:
@lolmaus commented on GitHub (Oct 26, 2020):
Stumbled upon this: https://github.com/jashkenas/backbone/issues/2888#issuecomment-29076249
It was said back in 2013! Basically, the same argumentation as I did a few messages above.
@lolmaus commented on GitHub (Oct 26, 2020):
Also this:
https://sedimental.org/calver.html
https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e (2014)
It's nice to know that I'm not the only one seeing all these flaws of SemVer. Participating in this thread made be doubt my sanity. My idea was even directly called insane. Well, turns out I'm not the only insane developer thinking so.
@mk-pmb commented on GitHub (Oct 26, 2020):
Which one? I don't know of any that actually enforces SemVer compliance. Then again, the only one I use that tries (futile) to establish SemVer is npm, and npm has enough other problems to show that it shouldn't be relied upon.
Glad you meanwhile found that a lot of real projects don't use SemVer. Does that mean we can now agree on that there are indeed real, viable alternatives to SemVer, that it's not a monopoly, and people are indeed free to use HumanVer instead?
@lolmaus commented on GitHub (Oct 26, 2020):
Yeah, that's the one. 😔 I'm happy to learn that other package managers are more relaxed about it. But I'm a frontend dev and it's npm I'm targeting for. 😔
It's not really practical not to be using npm in frontend development. If you share your package elsewhere, e. g. GitHub Packages, consumers need extra steps to make them work. 👎
@mk-pmb commented on GitHub (Oct 26, 2020):
Why would they? The npm cli supports various flavors of Github repo URLs as dependency spec. Besides, in my experience the npm registry accepts any number triplet as long as it's ascending. If your audience expects your package to use SemVer, you might need to clarify expectations in your Readme, but other than that, I see no SemVer limitations on npm.
@flashist commented on GitHub (Nov 9, 2020):
@lolmaus , I am not sure if it would matter or not, but, please, receive my rays of support in your fight for the 4th number or another way of indicating project generations.
I raised the same question about a week ago in the npm-discussion thread (where other ppl mentioned this ticket): https://github.com/npm/rfcs/discussions/271#discussioncomment-123359
It's a pity that you closed this ticket about 2 weeks ago. And it's a surprise for me that the ticket was created in 2014, and since then it hasn't received somewhat important support.
@ghost commented on GitHub (Nov 9, 2020):
@FichteFoll
The same argument can be made for how SemVer is implemented today, where a lot of software rarely exceeds the
0major version.@lolmaus
Rethinking my previous argument against the generation number, I do see its uses. With all the discussion in this thread, a clear-cut agreement needs to be made by the parties involved (consolidation) for the generation number or an official proposal needs to be written.
If someone wants to write a proposal, I would recommend keeping the "spirit of SemVer" in mind while writing it. For example, don't completely rewrite the specification. The proposal should be written as an extension of SemVer, not rewriting SemVer completely.
@lolmaus commented on GitHub (Feb 11, 2025):
More than a decade later, people start catching up on the idea of a "generation" vesrion number: https://www.youtube.com/watch?v=5TIDnT9LTFc
@lolmaus commented on GitHub (Feb 11, 2025):
I'm gonna reopen this. Hopefully, the proposal gets some traction after big guys like @t3dotgg have chimed in.
@mk-pmb commented on GitHub (Feb 11, 2025):
I think a new issue with a recap of the old discussion, and link to here, would be better. I for one don't have the nerve to read up on this long issue now a decade later, and most new arrivals probably won't either.
@FichteFoll commented on GitHub (Feb 11, 2025):
Please also provide a link to the source blog article instead of just someone reading it out loud on YouTube: https://antfu.me/posts/epoch-semver.
@steveklabnik commented on GitHub (Feb 12, 2025):
Sorry, this isn't going to happen. If you'd like a fourth number, please make your own specification. Semver is "done" in this regard.
@mk-pmb commented on GitHub (Feb 12, 2025):
@FichteFoll
Thanks for sharing the blog post.
@steveklabnik
I think it might be worth adding a paragraph to the Summary with something like:
That appendix would then be a good place to link to the blog article. Each appendix should be in a separate file.