7 ms·

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 Vers

by fenomas 10y ago

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 compatibility, then it doesn't need semver. Complaining that semver is bad for human readability is like saying hammers are an antipattern because you don't use nails.

thunderbong 10y ago
URL: http://semver.org/ http://semver.org/
taeric 10y ago
You do know that developers are humans, right?
fjdlwlv 10y ago
Because people who have read the spec don't have anything to complain about. When only nonsense is written against an idea, it's great , it shows the idea is great
stormbrew 10y ago
I mean, yes, sure. But the spec is not the world, and there is a general trend towards literally forcing things to adopt semver even when it makes little sense. If you write a project in rust, for example, you must give it a semver number in your cargo.toml. You can give it one that makes no sense and maybe never change it or change it arbitrarily, but the implication of that field is always that it's semver. It's right there in the docs: http://doc.crates.io/manifest.html http://doc.crates.io/manifest.html This is a real procedural problem that is being created by a "silver bullet" approach to versioning that the semver people can deny they're trying to create, but is happening anyways.
- grey-area 10y ago
  Isn't cargo a tool for sharing code? If you share code you should use semver, because someone will (hopefully) import it and use it, and it communicates your expectations of stability.
- justicezyx 10y ago
  Given that the article did a poor job of actually stating the problem of semver, could you list the issues you encountered when dealing with rust's use of semver? I worked at Amazon for 1 year. They use semver for everything. I think that's one of a few technical superiority I missed since left. I am curious about its problems. The article did not say much. As for the suggestion given in the article, I cannot help to think that one can always release a number based on a semver to external customers. That does not prevent semver being used internally at all. > a general trend towards literally forcing things to adopt semver This statement assumes that semver is bad if forced universally, which may or may not be the case. Your comment include no fact that this is bad. When you mentioning rust, you also did not say anything why semver is bad. I mean, if someone put an arbitrary number there, and users are screwed because of author fails to maintain the correct contract, at least people can go to there and point out that the contract is broken. Removing semver does not do anything good. It just give the author an possible excuse, i.e., if users are screwed, the author can claim that he/she never meant to make its software backward compatible. For that, semver also provides the same mechanism, i.e., bump a major version number. At lease users know that they can expect a breakage.
  - stormbrew 10y ago
    The article is poor, I'll agree with that. But the project I work on that makes me agree with it (that does not currently use rust, but it is something we're looking at) is a low level system component that is continuously deployed across entire clusters. We only ever have two versions active in a cluster at a time (either upgrading or downgrading when something goes wrong). People do not really 'consume' us except in so far as the system as a whole does expected things. We do have some "API"s to our system, and we do version those, but those protocols change extremely infrequently and are either only for consumption by the same or adjacent versions. Our release version numbers are literally jenkins build numbers. Anything else is not worth the administrative overhead for our needs (even were that 'small', it's also weirdly political in a bikeshed sort of way). And I don't think this is really all that uncommon even for higher level things. I don't think semver makes any sense for a rails app, for example, but in rubyland you only version things you publish. Rust makes you version things you will never publish. Don't get me wrong. For the things we consume from outside our team or abroad, semver is an absolute boon. Sometimes, though, when you point out that people are treating something as a silver bullet, you're saying it's outright bad. I'm not saying that. It's not a problem with semver that semver is not universally applicable.
qwtel 10y ago
If knowing every detail of something was required for criticising it, writing a massive, incomprehensible document would be an effective way to dismiss any criticism out of hand.
- gkya 10y ago
  This is the best Trumpism that I ever read anywhere. Even the Donald himself wouldn't be capable of such perfection.
  - qwtel 10y ago
    i take that as a compliment.
nstart 10y ago
First thought when reading this article. I fell into this trap too when developing my software stuff and then realised that I was just trying to force something that didn't make sense. My apps don't contain anything that has breaking changes for anyone else. And since then I've become more pragmatic about versioning. Now I don't really bother when it comes to web apps I build. The git commit id hash is good enough for me.
- davvid 10y ago
  If you need a version number then a very pragmatic thing to do is to just tag the repo something short and memorable once, e.g. "v1", and then use the output of "git describe --first-parent" as your version number from that point forward. The benefit is that you get the object ID along with an automatic counter of the # of commits since the last tag, which is basically a nice, automatic version number that you only very rarely need to update (by creating a new tag). $ git tag -m'app v1' v1 $ git describe --first-parent v1 # hack hack hack $ git commit -m'subsystem: some new feature' $ git describe --first-parent v1-1-gab2fcd9 # hack hack hack $ git commit -m'subsystem: some other new feature' $ git describe --first-parent v1-2-gc37ed42 The "v1-<number>-" prefix makes it much easier for a human to understand when read in logs, since the numbers are typically incrementing, and the strings are understood by Git as valid object IDs so it's easy to lookup the commit.
  - rollulus 10y ago
    I came here to mention exactly this. Being able correlate artefacts with code through embedded versions that contain the output of git describe is worth tons.
- demircancelebi 10y ago
  I suggest `commitizen` if you are working with a group. We use it with npm package `standard-version` to keep an auto generated CHANGELOG.md file.
andrewingram 10y ago
The way I tend to version websites/apps is: {visible-feature-changes}.{anything-else}
csours 10y ago
I use screws and bolts in my construction, and hammers are definitely an anti-pattern.

by fenomas 10y ago

thunderbong 10y ago

URL: http://semver.org/ http://semver.org/

taeric 10y ago

You do know that developers are humans, right?

fjdlwlv 10y ago

Because people who have read the spec don't have anything to complain about. When only nonsense is written against an idea, it's great , it shows the idea is great

stormbrew 10y ago

I mean, yes, sure. But the spec is not the world, and there is a general trend towards literally forcing things to adopt semver even when it makes little sense. If you write a project in rust, for example, you must give it a semver number in your cargo.toml. You can give it one that makes no sense and maybe never change it or change it arbitrarily, but the implication of that field is always that it's semver. It's right there in the docs: http://doc.crates.io/manifest.html http://doc.crates.io/manifest.html This is a real procedural problem that is being created by a "silver bullet" approach to versioning that the semver people can deny they're trying to create, but is happening anyways.

grey-area 10y ago
Isn't cargo a tool for sharing code? If you share code you should use semver, because someone will (hopefully) import it and use it, and it communicates your expectations of stability.
justicezyx 10y ago
Given that the article did a poor job of actually stating the problem of semver, could you list the issues you encountered when dealing with rust's use of semver? I worked at Amazon for 1 year. They use semver for everything. I think that's one of a few technical superiority I missed since left. I am curious about its problems. The article did not say much. As for the suggestion given in the article, I cannot help to think that one can always release a number based on a semver to external customers. That does not prevent semver being used internally at all. > a general trend towards literally forcing things to adopt semver This statement assumes that semver is bad if forced universally, which may or may not be the case. Your comment include no fact that this is bad. When you mentioning rust, you also did not say anything why semver is bad. I mean, if someone put an arbitrary number there, and users are screwed because of author fails to maintain the correct contract, at least people can go to there and point out that the contract is broken. Removing semver does not do anything good. It just give the author an possible excuse, i.e., if users are screwed, the author can claim that he/she never meant to make its software backward compatible. For that, semver also provides the same mechanism, i.e., bump a major version number. At lease users know that they can expect a breakage.
- stormbrew 10y ago
  The article is poor, I'll agree with that. But the project I work on that makes me agree with it (that does not currently use rust, but it is something we're looking at) is a low level system component that is continuously deployed across entire clusters. We only ever have two versions active in a cluster at a time (either upgrading or downgrading when something goes wrong). People do not really 'consume' us except in so far as the system as a whole does expected things. We do have some "API"s to our system, and we do version those, but those protocols change extremely infrequently and are either only for consumption by the same or adjacent versions. Our release version numbers are literally jenkins build numbers. Anything else is not worth the administrative overhead for our needs (even were that 'small', it's also weirdly political in a bikeshed sort of way). And I don't think this is really all that uncommon even for higher level things. I don't think semver makes any sense for a rails app, for example, but in rubyland you only version things you publish. Rust makes you version things you will never publish. Don't get me wrong. For the things we consume from outside our team or abroad, semver is an absolute boon. Sometimes, though, when you point out that people are treating something as a silver bullet, you're saying it's outright bad. I'm not saying that. It's not a problem with semver that semver is not universally applicable.

qwtel 10y ago

If knowing every detail of something was required for criticising it, writing a massive, incomprehensible document would be an effective way to dismiss any criticism out of hand.

gkya 10y ago
This is the best Trumpism that I ever read anywhere. Even the Donald himself wouldn't be capable of such perfection.
- qwtel 10y ago
  i take that as a compliment.

nstart 10y ago

First thought when reading this article. I fell into this trap too when developing my software stuff and then realised that I was just trying to force something that didn't make sense. My apps don't contain anything that has breaking changes for anyone else. And since then I've become more pragmatic about versioning. Now I don't really bother when it comes to web apps I build. The git commit id hash is good enough for me.

davvid 10y ago
If you need a version number then a very pragmatic thing to do is to just tag the repo something short and memorable once, e.g. "v1", and then use the output of "git describe --first-parent" as your version number from that point forward. The benefit is that you get the object ID along with an automatic counter of the # of commits since the last tag, which is basically a nice, automatic version number that you only very rarely need to update (by creating a new tag). $ git tag -m'app v1' v1 $ git describe --first-parent v1 # hack hack hack $ git commit -m'subsystem: some new feature' $ git describe --first-parent v1-1-gab2fcd9 # hack hack hack $ git commit -m'subsystem: some other new feature' $ git describe --first-parent v1-2-gc37ed42 The "v1-<number>-" prefix makes it much easier for a human to understand when read in logs, since the numbers are typically incrementing, and the strings are understood by Git as valid object IDs so it's easy to lookup the commit.
- rollulus 10y ago
  I came here to mention exactly this. Being able correlate artefacts with code through embedded versions that contain the output of git describe is worth tons.
demircancelebi 10y ago
I suggest `commitizen` if you are working with a group. We use it with npm package `standard-version` to keep an auto generated CHANGELOG.md file.

andrewingram 10y ago

The way I tend to version websites/apps is: {visible-feature-changes}.{anything-else}

csours 10y ago

I use screws and bolts in my construction, and hammers are definitely an anti-pattern.