4 ms·

Honest question: How do you feel e.g. "1.2.1 => 1.6.2" is more useful than for instance incorporating dates, like: "2020.05.04 => 2020.06.20"? From my perspect

Honest question: How do you feel e.g. "1.2.1 => 1.6.2" is more useful than for instance incorporating dates, like: "2020.05.04 => 2020.06.20"? From my perspective both schemes provide useful information but for different purposes.

striking 6y ago
You can issue a patch for 1.2 even after releasing 1.6.2 using semver
- yjftsjthsd-h 6y ago
  You can even maintain 1.2.x and 2.5.y and 3.3.z at the same time:) (It can be a right pain, yes, but we couldn't break our downstream so we were stuck with backports of new features... well, backports and living with the old versions)
usrusr 6y ago
Strict semver all too often ends up "47.0.0 => 53.0.0" because in the spirit of xkcd 1172 "every change breaks someone's workflow" almost everything can be seen as an API change. 47=>53 could be a quick succession of tiny but technically breaking fixes in some backwater part of the API that hardly anyone uses or it could include a once-in-a-decade major API redesign or two.
- yjftsjthsd-h 6y ago
  I honestly feel like that's a symptom of a poor API design in the first place, although I'm willing to agree that there can be a little wiggle room in the "is it a breaking change if someone depends on a bug?" middle. If you have to bump your major that often, at best maybe consider why, and at worst at least you're still making it clear to the downstream users that that's what's happening! Better to explicitly mark "yeah, we broke API compatibility again" rather than "we incremented the version integer again; good luck finding out why unless you read the complete changelog".
  - usrusr 6y ago
    A lot depends on typed on typedness. If breaking changes are identified during compilation then the cost of minor breakage somewhere is low. The quantity of change is far more interesting than strict absence/presence. And it takes so little change to get unexpected client code broken that I'm very sceptical of attempts to prevent it in API design. Take classic java for example. If you have a public interface adding a method can break someone's client code because nothing can keep them from implementing that interface and the implementing class might already have a method with a colliding interface. If you went completely over the top with compatibility expectations you could even argue that it's impossible (pre-modules I think?) to add any class or interface at all because someone at foo.com might have rudely put a client code class with the same name in your precious org.bar namespace. Nothing in the language prevents that. Trying to design out the possibility of breakage isn't worth it, you'll end up with conventions that soften the definition of "breaking change" anyways (or with the antipattern of major-only increments)
- usrusr 6y ago
  PS: on the topic of timestamps, I think that the bugfix level would be much better served with a date than with an increment. A "2.7.3" could be both much older or much younger than the corresponding "2.5.6" or contain exactly the same important fixes. When assessing the risk of running something that contains an older version your most important information is often before or after $famousvulnerability and increments can be quite deceptive. I think I might be happy with major.minor.date, where both major and minor are allowed to be breaking, with meaning "most client codebases will need change" and minor means "most client codebases will be fine". For languages leaning towards typed I'd lump the "only added features" together with minor breakage, for more dynamic languages the existing semver (plus date instead of bugfix increment) is probably fine.
lolsal 6y ago
I would say that I would confidently update from: "1.2.1" -> "1.2.6" without batting an eyelash if my tests passed. "1.2.1" -> "1.6.2" would give me pause, but I wouldn't shy away from it. Going from "2020.05.04 => 2020.06.20" doesn't tell me _anything what so ever_ about backwards compatibility or risk that I'm taking on. Is that the equivalent of going from "1.x to "2.x" or "1.x" to "8.x"? Who knows.
- lillesvin 6y ago
  As I said, from my perspective they're useful for different purposes. I've worked on software (internal sales system) that the end-users were interacting directly with. They'd always be running the latest version and thus versioning by dates would have been a lot more tangible to them. Over the course of 5 years and several thousand bug reports from end-users and 2nd/3rd line support I've never once seen a bug report that mentioned a version number. It was always "the version that was deployed last week" or something to that effect despite the version number being visible in the app at all times. For APIs and libraries semver makes a lot of sense, I agree, but not all code is APIs or libraries.
tus88 6y ago
Dates tell you squat all.
- lillesvin 6y ago
  That certainly depends on who's using the code. I've worked on both APIs used by other developers and software used directly by end-users. For the latter, dates would have worked much better than version numbers since the end-users couldn't choose what version they used anyway and version numbers didn't mean anything to them. For APIs or libraries, yeah, semver is cool and dandy, but not all code is APIs or libraries.

striking 6y ago

You can issue a patch for 1.2 even after releasing 1.6.2 using semver

yjftsjthsd-h 6y ago
You can even maintain 1.2.x and 2.5.y and 3.3.z at the same time:) (It can be a right pain, yes, but we couldn't break our downstream so we were stuck with backports of new features... well, backports and living with the old versions)

usrusr 6y ago

Strict semver all too often ends up "47.0.0 => 53.0.0" because in the spirit of xkcd 1172 "every change breaks someone's workflow" almost everything can be seen as an API change. 47=>53 could be a quick succession of tiny but technically breaking fixes in some backwater part of the API that hardly anyone uses or it could include a once-in-a-decade major API redesign or two.

yjftsjthsd-h 6y ago
I honestly feel like that's a symptom of a poor API design in the first place, although I'm willing to agree that there can be a little wiggle room in the "is it a breaking change if someone depends on a bug?" middle. If you have to bump your major that often, at best maybe consider why, and at worst at least you're still making it clear to the downstream users that that's what's happening! Better to explicitly mark "yeah, we broke API compatibility again" rather than "we incremented the version integer again; good luck finding out why unless you read the complete changelog".
- usrusr 6y ago
  A lot depends on typed on typedness. If breaking changes are identified during compilation then the cost of minor breakage somewhere is low. The quantity of change is far more interesting than strict absence/presence. And it takes so little change to get unexpected client code broken that I'm very sceptical of attempts to prevent it in API design. Take classic java for example. If you have a public interface adding a method can break someone's client code because nothing can keep them from implementing that interface and the implementing class might already have a method with a colliding interface. If you went completely over the top with compatibility expectations you could even argue that it's impossible (pre-modules I think?) to add any class or interface at all because someone at foo.com might have rudely put a client code class with the same name in your precious org.bar namespace. Nothing in the language prevents that. Trying to design out the possibility of breakage isn't worth it, you'll end up with conventions that soften the definition of "breaking change" anyways (or with the antipattern of major-only increments)
usrusr 6y ago
PS: on the topic of timestamps, I think that the bugfix level would be much better served with a date than with an increment. A "2.7.3" could be both much older or much younger than the corresponding "2.5.6" or contain exactly the same important fixes. When assessing the risk of running something that contains an older version your most important information is often before or after $famousvulnerability and increments can be quite deceptive. I think I might be happy with major.minor.date, where both major and minor are allowed to be breaking, with meaning "most client codebases will need change" and minor means "most client codebases will be fine". For languages leaning towards typed I'd lump the "only added features" together with minor breakage, for more dynamic languages the existing semver (plus date instead of bugfix increment) is probably fine.

lolsal 6y ago

I would say that I would confidently update from: "1.2.1" -> "1.2.6" without batting an eyelash if my tests passed. "1.2.1" -> "1.6.2" would give me pause, but I wouldn't shy away from it. Going from "2020.05.04 => 2020.06.20" doesn't tell me _anything what so ever_ about backwards compatibility or risk that I'm taking on. Is that the equivalent of going from "1.x to "2.x" or "1.x" to "8.x"? Who knows.

lillesvin 6y ago
As I said, from my perspective they're useful for different purposes. I've worked on software (internal sales system) that the end-users were interacting directly with. They'd always be running the latest version and thus versioning by dates would have been a lot more tangible to them. Over the course of 5 years and several thousand bug reports from end-users and 2nd/3rd line support I've never once seen a bug report that mentioned a version number. It was always "the version that was deployed last week" or something to that effect despite the version number being visible in the app at all times. For APIs and libraries semver makes a lot of sense, I agree, but not all code is APIs or libraries.

tus88 6y ago

Dates tell you squat all.

lillesvin 6y ago
That certainly depends on who's using the code. I've worked on both APIs used by other developers and software used directly by end-users. For the latter, dates would have worked much better than version numbers since the end-users couldn't choose what version they used anyway and version numbers didn't mean anything to them. For APIs or libraries, yeah, semver is cool and dandy, but not all code is APIs or libraries.