4 ms·

There's a lot of things you can say about Semantic Versioning, but it's hard to say that it isn't semantic. What is it, then? Syntactic? Temporal? The fact of

There's a lot of things you can say about Semantic Versioning, but it's hard to say that it isn't semantic. What is it, then? Syntactic? Temporal? The fact of the matter is that Semantic Versioning does capture something about the behavior of the release relative to others. It helps you answer the question, given the same inputs (where input can be defined as a sequence of API calls and their arguments), will these two versions produce the same results? That is inherently a question of the semantics of the libraries. In fact it's very similar to the question that the Liskov substitution principle[0] asks of objects and their classes, but using software libraries as the reusable, swappable component. People make mistakes with Semantic Versioning. Sometimes, they just flat out don't care. The fallibility of a humanity is no excuse to throw out a perfectly good concept that can be very useful even when executed improperly, given that no other system is at hand to assist with the complex task of building large software projects out of a bunch of smaller parts. Properly understanding what the "semantic" in Semantic Versioning means can go a long way. For example, if semantics is what the version number is looking to capture, perhaps a good place to turn when deciding how to bump a version is tests. Have they changed? How so? If you're doing property-based testing, answering this question becomes even easier. [0]: http://en.wikipedia.org/wiki/Liskov_substitution_principle http://en.wikipedia.org/wiki/Liskov_substitution_principle

taeric 12y ago
Well, at some point the argument regarding the "semantic" nature of the build numbers is just silly. Especially in today's world where it is very possible that you could do things in a version 1.x.x of a product that you can not do in a version 2+.x.x. Anyone that just takes in any x.x.y update is asking for trouble if they don't have good testing in place. How does the saying go, "one developer's bug is some user's feature?" That is, if the only real meaning I can get is that "these two aren't compatible," I don't care what friggin scheme you did. I confess that I am particularly annoyed with semantic versioning romance where it is deemed capable of solving all dependency issues internally to a company. To that point, this piece really resonated with me. But, at the end of the day, I don't particularly care that there is "some breaking change" between two versions much more than I care that there were additional methods added. In the end, I want to know exactly what changed between things. As such, a changelog and a non-automated update system that is audited and purposely used is much preferrable to the promise of semantic versioning. Though, I do have to cede that the promise of semantic versioning is better than the reality of never updating that happens for many folks.
- seliopou 12y ago
  1. That some things are possible 1.x.x that aren't possible in 2+.x.x is a fact that nobody would deny, and is consistent with semantic versioning. The point is to clarify the vague terms of "compatibility" and "breaking" by tying them to semantics of the library, as described above. Ultimately, this is a determination made by the developer. Any responsible operator is going to test before deploying, and that's how it should be regardless of versioning scheme. 2. In combination with automated testing, it can go a long way. 3. The first part doesn't make any sense to me. As to the second part, semantic versioning and a changelog are not mutually exclusive. In fact, the practice of maintaining semantic versions typically leads to much higher quality changelogs. 4. Yes, the question is: If not semantic versioning, then what?
  - taeric 12y ago
    For me, the answer would be conscious upgrades of dependencies with a thoughtful view of the changelog. Of course, I think I would also prefer less of a web of dependencies between so many different things now. It is almost comical. A few years ago, the complaint was that something like Java's JButton would have upwards of 160+ methods from the web of interfaces and superclasses it came from. Seems that today, that web "you can't possibly comprehend it" lies more in the dependencies of a product than in the individual classes. And this only gets worse as some dependencies grow to encompass more and more.

taeric 12y ago

Well, at some point the argument regarding the "semantic" nature of the build numbers is just silly. Especially in today's world where it is very possible that you could do things in a version 1.x.x of a product that you can not do in a version 2+.x.x. Anyone that just takes in any x.x.y update is asking for trouble if they don't have good testing in place. How does the saying go, "one developer's bug is some user's feature?" That is, if the only real meaning I can get is that "these two aren't compatible," I don't care what friggin scheme you did. I confess that I am particularly annoyed with semantic versioning romance where it is deemed capable of solving all dependency issues internally to a company. To that point, this piece really resonated with me. But, at the end of the day, I don't particularly care that there is "some breaking change" between two versions much more than I care that there were additional methods added. In the end, I want to know exactly what changed between things. As such, a changelog and a non-automated update system that is audited and purposely used is much preferrable to the promise of semantic versioning. Though, I do have to cede that the promise of semantic versioning is better than the reality of never updating that happens for many folks.

seliopou 12y ago
1. That some things are possible 1.x.x that aren't possible in 2+.x.x is a fact that nobody would deny, and is consistent with semantic versioning. The point is to clarify the vague terms of "compatibility" and "breaking" by tying them to semantics of the library, as described above. Ultimately, this is a determination made by the developer. Any responsible operator is going to test before deploying, and that's how it should be regardless of versioning scheme. 2. In combination with automated testing, it can go a long way. 3. The first part doesn't make any sense to me. As to the second part, semantic versioning and a changelog are not mutually exclusive. In fact, the practice of maintaining semantic versions typically leads to much higher quality changelogs. 4. Yes, the question is: If not semantic versioning, then what?
- taeric 12y ago
  For me, the answer would be conscious upgrades of dependencies with a thoughtful view of the changelog. Of course, I think I would also prefer less of a web of dependencies between so many different things now. It is almost comical. A few years ago, the complaint was that something like Java's JButton would have upwards of 160+ methods from the web of interfaces and superclasses it came from. Seems that today, that web "you can't possibly comprehend it" lies more in the dependencies of a product than in the individual classes. And this only gets worse as some dependencies grow to encompass more and more.