3 ms·

I'll abuse it all I like. At the end of the day it's a format standard for versions, whether you use it semantically or not. It has a well designed mechanism fo

I'll abuse it all I like. At the end of the day it's a format standard for versions, whether you use it semantically or not. It has a well designed mechanism for comparing versions. It allows adding of meta data to the version, so you can build what commit, and what build run on your CI system built it, or any other things you want. Many tools understand it. I really struggle to see any meaningful downside in using semver, even if you don't do it semantically, if all you really need is some ever increasing number that is trackable through your system, it does that job as well.

lokedhs 6y ago
This is actually a very reasonable response, if only delivered in a somewhat dismissive way. I believe the point is that even if you follow the recommendations to the letter, and do everything correctly and never even accidentally change API behaviour between minor versions, anyone using your product still cannot be sure that that is actually the case. When I upgrade a piece of software, can I rely on the version number actually reflecting the compatibility? Of course not. As long as even a minority of software doesn't follow these recommendations (and to be realistic, they never will) you can never actually rely on these numbers for anything useful in the general case. In the special case, sure. Some vendors have very strict compatibility guarantees and that is really useful. But to take advantage of these guarantees you need to read their documentation on the topic, and if you read the documentation it doesn't really matter what versioning scheme they follow.
q3k 6y ago
> I really struggle to see any meaningful downside in using semver, even if you don't do it semantically, It erodes the social contract of semver. Without a common understanding and trust of semver you lose the ability to have an educated guess on whether 2.4.3->2.5.0 is an API-breaking change. Naturally, you cannot truly rely on this anyway (and dependency versions updates need to be tested), but being able to have a general idea about your dependencies' API breakage at a glance is a great help. This becomes even more important in the case of transitive depdencies: something that might be drive-by bumped by your direct dependency (satisfied by the fact that it's only a minor release bump and _their_ use doesn't break) might actually cause your direct use of that transitive dependency to break.
- joppy 6y ago
  What is the social contract of semver, as a library consumer? If either the patch or minor versions change, I should not care since everything is backwards compatible. But if the major version changes, all bets are off. This seems like almost no contract at all. It seems to me that this same information could be communicated by combining the minor and patch versions into one number, and changing the name of the library rather than changing the major version number.
  - sixstringtheory 6y ago
    I like having the patch number set apart. I frequently run into bugs with dependencies where the first thing I check is if they've released a patch, so I can try that to fix the bug before digging any deeper. Muddle that with minor revisions and that information is lost. Minor revisions, in addition to signaling new functionality, also signal the possibility of the introduction of new bugs.
    - joppy 6y ago
      So both patch versions and minor versions signal the possibility of introduction of new bugs - is there a point to separating them?

lokedhs 6y ago

This is actually a very reasonable response, if only delivered in a somewhat dismissive way. I believe the point is that even if you follow the recommendations to the letter, and do everything correctly and never even accidentally change API behaviour between minor versions, anyone using your product still cannot be sure that that is actually the case. When I upgrade a piece of software, can I rely on the version number actually reflecting the compatibility? Of course not. As long as even a minority of software doesn't follow these recommendations (and to be realistic, they never will) you can never actually rely on these numbers for anything useful in the general case. In the special case, sure. Some vendors have very strict compatibility guarantees and that is really useful. But to take advantage of these guarantees you need to read their documentation on the topic, and if you read the documentation it doesn't really matter what versioning scheme they follow.

q3k 6y ago

> I really struggle to see any meaningful downside in using semver, even if you don't do it semantically, It erodes the social contract of semver. Without a common understanding and trust of semver you lose the ability to have an educated guess on whether 2.4.3->2.5.0 is an API-breaking change. Naturally, you cannot truly rely on this anyway (and dependency versions updates need to be tested), but being able to have a general idea about your dependencies' API breakage at a glance is a great help. This becomes even more important in the case of transitive depdencies: something that might be drive-by bumped by your direct dependency (satisfied by the fact that it's only a minor release bump and _their_ use doesn't break) might actually cause your direct use of that transitive dependency to break.

joppy 6y ago
What is the social contract of semver, as a library consumer? If either the patch or minor versions change, I should not care since everything is backwards compatible. But if the major version changes, all bets are off. This seems like almost no contract at all. It seems to me that this same information could be communicated by combining the minor and patch versions into one number, and changing the name of the library rather than changing the major version number.
- sixstringtheory 6y ago
  I like having the patch number set apart. I frequently run into bugs with dependencies where the first thing I check is if they've released a patch, so I can try that to fix the bug before digging any deeper. Muddle that with minor revisions and that information is lost. Minor revisions, in addition to signaling new functionality, also signal the possibility of the introduction of new bugs.
  - joppy 6y ago
    So both patch versions and minor versions signal the possibility of introduction of new bugs - is there a point to separating them?