71–80 of 219 posts
Why is it that every time there's an article criticizing semver, the author never seems to have bothered looking at the spec? > 1. Software using Semantic Versioning MUST declare a public API. That's the very first thing it says. Semver is not meant for general apps or websites or the like, it's for APIs against which dependencies can be declared . If your software doesn't need to tell package managers about its comp…
The author seems to be completely missing the boat here. SemVer isn't meant for Continuous Delivery production systems. Why would you even attempt to use it for that? SemVer is for libraries, and specifically for making dependency management easy. If you're not writing a library that gets distributed to other people, then use whatever versioning system you want.
> Why would you even attempt to use it for that? Can you name a package management tool that doesn't rely on SemVer?
In any case, none of the things you use SemVer for are Continuous Delivery always-on production systems. They're software releases.
Semver is all about creating reliable builds from dependencies.
Sometimes a "software package" encompasses multiple concurrent "API versions", which means that depending on whether you care about the API in question, the package may or may not be changing something you care about. When it's unified to a single package-wide version then you have no idea. As Rich Hickey put it in his talk on the subject[0], all you know is that "something changed."
[0] https://news.ycombinator.com/item?id=13085952 (video link + comment thread)
Earlier quoted context omitted.
My biggest beef with semver is that it is pushed by people encouraging this concept that additions are always safe. Or the lie that people will do security and other updates on older versions. By and large, especially in an org, if you make a change that requires another place to change, you should go ahead and make that change. Period. Thinking people can stay on the old version till they want to update is BS. They…
It used to work that way, though; software in the 90s and early 2000s did have sane semantic versioning, updates were backported to earlier major versions, and revision updates generally didn't break anything in production. I bet semantic versioning is mostly championed by older veterans who have worked in maintenance or systems administration roles and are trying to get the industry to return to a versioning system…
Earlier quoted context omitted.
My biggest beef with semver is that it is pushed by people encouraging this concept that additions are always safe. Or the lie that people will do security and other updates on older versions. By and large, especially in an org, if you make a change that requires another place to change, you should go ahead and make that change. Period. Thinking people can stay on the old version till they want to update is BS. They…
I agree, SemVersion is a technical solution for what is often a human/corporate problem. A good solution to this is to have an "edge" build that will upgrade dependencies and let you know about breakages early, but that still requires companies to acknowledge that all software needs maintaining.
I never really liked semver as its a mixture of release number and an abstraction/categorization of risk that nobody can agree on, making it hard to tell how stable an update will be. It was fine back when you only had a release or two a year, but now the abstraction is no longer good enough. I prefer the first number to be a simple release number, then the second to be the amount of risk from the previous release. T…
What do you mean by risk? How would you quantify it? As I understand it, all semver is trying to tell you is when backwards-compatible changes happen, and when backwards-incompatible changes happen. If the project developer wants to add some sort of indication that "this package contains changes that are alpha quality, and may not respect semver for the next few releases" then that developer can append a pre-release…
For example, a change in the public signature of a function to accept a wider class of arguments might be considered backwards-compatible since the previous calls to the function will still work.
But if your language has type inference, now the previous calls have to actually specify the type of their arguments since the type inference algorithm can no longer resolve all the types.
So you can break SOMEONE'S build by accepting more types of arguments. It will be a one line fix, but if that fix has to be made upstream...
Earlier quoted context omitted.
> Why would you even attempt to use it for that? Can you name a package management tool that doesn't rely on SemVer?
I'm not sure what you're trying to say. I explicitly said SemVer is for libraries and specifically for dependency management. So yeah, package managers use SemVer for dependencies. In theory you could also extend this to programming languages, but most programming languages don't do SemVer. I suppose other build tools also qualify. In any case, none of the things you use SemVer for are Continuous Delivery always-on p…
Earlier quoted context omitted.
IME this problem is particular to NPM, due to JavaScript's historically-anemic standard library which made a culture of microlibraries inevitable. The lesson is that programming languages should provide rich operations on their standard types so that users can avoid having to transitively depend on ten different versions of left-pad.
The problem might be particularly bad in NPM but it is not unique too it.
Rich Hickey's recent talk https://youtu.be/oyLBGkS5ICk?t=2790 tore into semver. Recommended.
The reasons that Rich Hickey tore into SemVer seem to be issues SemVer weren't concerned about solving and his alternatives doesn't solve the main issue SemVer was created for. The problem of "can I reasonably upgrade this library without breaking my own code, and if possible to so in an automated fashion" isn't solved by chronological versioning. If I need to upgrade my application due to a security vuln, SemVer let…
He does talk explicitly about the trouble of making major changes in SemVer[0]. The gist of his argument was that minor changes in semver are relatively useless while major changes have a high probability of breaking your software. Major changes in semver are backwards incompatible and update the program's API in place. This leads to dowstream breakage and fear around doing upgrades.
> If I need to upgrade my application due to a security vuln, SemVer lets me know if I can just "drop-in" the upgrade, or if I need to work more.
I think the point he was trying to make was that upstream developers could change internals of a library but keep the API consistent so that downstream devs would never have to worry about scary updates. As you said with SemVer, if the security upgrade is a significant change, then you can expect breakage in the library. What he was advocating was patching issues like security vulns under the hood while keeping everything backwards compatible. Major upgrades could even add new namespaces, functions, and arguments but there's no real point to deleting or mutating old code, that just creates breakage. He wants software libraries to be immutable to take care of dependency issues and versioning to better reflect the changes made in the code.
[0]https://youtu.be/oyLBGkS5ICk?t=13m45s