SemVer versions communicate only a small amount of information. But that’s better than zero information, which is what non-SemVer policies usually accomplish. If you have a better policy than SemVer, by all means use that, document it on your site, and everyone will be happy. But if, like Ashkenas and everyone who’s criticized SemVer before or since, you don’t actually have a better alternative (other than maybe “human judgement”, which turns out not to be better), then stick to SemVer (I’m reminded of the fallacy of gray).
Maybe in our lifetimes we’ll have a language and toolchain that will be able to automatically prove/verify the worth of a dependency change to a given program. I wonder if anyone is working on that.
There are some useful tools in this area; at one of my previous jobs we used clirr to detect when we should do a major version bump (I believe animal sniffer does a similar thing). But such things can only detect changes the computer understands; to do this perfectly you’d have to either have the tool detect semantic code changes, or encode all your semantics in the type system (which is getting closer all the time with modern dependently typed languages, but not there yet).
Version numbers are a way of imposing a narrative upon a chaotic world. SHAs are the ground truth, but they’re too messy to deal with directly as humans, so we have to tell a story about the progression of one set of events to another. As long as you understand it for what it really is, I don’t see the problem.
SHA is a shortcut representation for a bitstream that is the software. They make it easy to communicate equality and nothing more.
What we need is to have a strong type system that understands the dependencies. All the problems we are dealing with stem from additional layers of abstraction enabled by fast machine and more expensive programmers. Virtualization and containerization are really an answer to incompatible imperative state and a lack of static linking. SemVer is a weak dynamic link, we need strong static links. SemVer makes DLL hell slightly more palatable but it doesn’t fix the problem.
Semver is prescriptive, not descriptive. It tells you, as a library developer, shat sort of changes you can make if you want to release a library under a specific version.
If you want people to use your software without becoming intimately familiar with the development cycle, semver numbers are the abstraction you provide.
SemVer versions communicate only a small amount of information. But that’s better than zero information, which is what non-SemVer policies usually accomplish. If you have a better policy than SemVer, by all means use that, document it on your site, and everyone will be happy. But if, like Ashkenas and everyone who’s criticized SemVer before or since, you don’t actually have a better alternative (other than maybe “human judgement”, which turns out not to be better), then stick to SemVer (I’m reminded of the fallacy of gray).
Maybe in our lifetimes we’ll have a language and toolchain that will be able to automatically prove/verify the worth of a dependency change to a given program. I wonder if anyone is working on that.
There are some useful tools in this area; at one of my previous jobs we used clirr to detect when we should do a major version bump (I believe animal sniffer does a similar thing). But such things can only detect changes the computer understands; to do this perfectly you’d have to either have the tool detect semantic code changes, or encode all your semantics in the type system (which is getting closer all the time with modern dependently typed languages, but not there yet).
Version numbers are a way of imposing a narrative upon a chaotic world. SHAs are the ground truth, but they’re too messy to deal with directly as humans, so we have to tell a story about the progression of one set of events to another. As long as you understand it for what it really is, I don’t see the problem.
SHA is a shortcut representation for a bitstream that is the software. They make it easy to communicate equality and nothing more.
What we need is to have a strong type system that understands the dependencies. All the problems we are dealing with stem from additional layers of abstraction enabled by fast machine and more expensive programmers. Virtualization and containerization are really an answer to incompatible imperative state and a lack of static linking. SemVer is a weak dynamic link, we need strong static links. SemVer makes DLL hell slightly more palatable but it doesn’t fix the problem.
Semver is prescriptive, not descriptive. It tells you, as a library developer, shat sort of changes you can make if you want to release a library under a specific version.
If you want people to use your software without becoming intimately familiar with the development cycle, semver numbers are the abstraction you provide.
If you need more evidence to poo poo on semver to your co-workers, I wrote about this same topic back in 2013: http://www.brandonbloom.name/blog/2013/06/19/semver/