11 ms·

> Among other things, it includes a cost-based optimizer that can complete the TPC-H benchmark, CDC, and two major enterprise security features. But was this en

by mcdee 7y ago

> Among other things, it includes a cost-based optimizer that can complete the TPC-H benchmark, CDC, and two major enterprise security features. But was this enough of a value jump to merit the leap to 3.0? Or was this a 2.2? Strictly following the semantic versioning rules would specify 2.2, as there are no backwards incompatible API changes. But with that logic guiding the major version bump, we could potentially remain on 2.x forever. The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations. The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does. Sounds like a triumph of marketing over useful information.

djsumdog 7y ago
They also mention in the article how they don't support skipping releases, so it sounds like you have to upgrade to each point release anyway? Really if you're not constantly updating dependencies as part of your pipelines, you're going to quickly get into dependency rot issues.
- web007 7y ago
  I'm always surprised at how often developers freeze a set of versions and leave them for a lifetime. In my past three companies I have been the only one interested in pushing dependencies on a regular basis. I always start with a massive backlog, and end up having to incrementally update from the Stone Age to $today. Once that's set and tests pass it's easy to keep things up-to-date, you end up with single-digit changes every month instead of ~100 every year. Do it this way and save yourself the pain of zillions of updates when you HAVE to bump a package for a CVE.
  - BurningFrog 7y ago
    Yet another case of "if it hurts, do it more often" https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
  - njharman 7y ago
    Word! And same for me at new jobs. I also tend to be the one who writes docs, gets testing automated, CI. Too many developers think banging out code as fast as they can is "doing their job well".
  - paulddraper 7y ago
    But the journey from A to B to C to D is longer than A to D. You can get whiplash from conforming to every change in the winds.
    - erik_seaberg 7y ago
      This. Skipping B and C needs to be managed like any other technical debt, but it can pay off. It's not your job to regression test every intermediate version of everyone's libraries.
lifthrasiir 7y ago
The problem of semver is that everyone interprets the compatibility differently. There are some language-supported criteria, but that does not cover all important use cases. In addition, any reasonable compatibility criteria might be impossible for large enough softwares---every revision can be potentially major in the semver terminology and it won't deliver much value to the user anyway. The calender versioning is useful for such cases.
- sametmax 7y ago
  I read that as "the problem with semver is it's not perfect". Well yeah. But no semver is worse: upgrading is hard enough when devs communicate on what breaks, but when they don't, it's just a nightmare. Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.
  - lifthrasiir 7y ago
    I think the language-backed semver can be useful (I really want Cargo to support this mode!). The general unguided semver seems less useful. I envision a much simplified alternative (or analogue) to the semver: there is a single decimal revision, and you should strive to be compatible back to the first revision. When you are willing to break the compatibility, you simply rename. This is similar to Go's practice but can be technically made compatible to the three-part semver (by encoding minor and patch versions to the decimal).
    - lugg 7y ago
      This is my issue with semver. I don't care about minor non breaking change, just give me the latest. Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right? So lib: 1.* Should be fine, right? But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?
      - 7y ago
y0ghur7_xxx 7y ago
> The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations. No. Semver states quite clearly that "Major version MUST be incremented if any backwards incompatible changes are introduced to the public API.". It does NOT state that the Major verson MUST NOT be incremented if the api has no backwards incompatible changes. You can increment the MAJOR component of the version number at your will. So this is quit clearly a 3.0.0 release. Or it could be a 40.0.0 release and it would still be valid semver.
- StavrosK 7y ago
  By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.
  - cormacrelf 7y ago
    Except that for it to remain both valid calver and valid semver, they would have to delay all breaking changes until January every time they come up.
    - StavrosK 7y ago
      They seem to indicate that they aren't expecting any more breaking changes, but yes, that's generally true.
  - Legogris 7y ago
    It's not valid if 19.2 introduces breaking changes form 19.1
  - trickstra 7y ago
    true, but doing that makes no sense, because people who made their software depend on major v18 are not switching automatically, because they first need to check if any breaking changes happened and if they need to modify their own software. Semver is "semantic" for a reason - to simplify this daunting task. Increasing major version even when there are no breaking changes is technically still semver, but without the helpful warranty, so it completely misses the point
simula67 7y ago
They could have picked Android's versioning scheme : a codename to signal significance and an API level to signal compatibility.
- kibwen 7y ago
  This right here. The only reason people observe tension between semantic versioning and romantic versioning is because prior to semantic versioning we spent decades conflating the version number to convey both "important new feature" and "incompatible changes". Both user marketing and technical compatibility guidance are important, but there's nothing that inherently says that both of these things need to be communicated via a single version number. Pick a nice-sounding word to market your version with big changes, and leave it unrelated to your API version.
NullPrefix 7y ago
>The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does. Old is bad, new is good. What else is there to understand?
- username223 7y ago
  "You now have Chrome/Firefox 277, which is different from version 276, and has installed itself. Deal with it, because there's no option to revert to version 276." That's just how software works these days.
treffer 7y ago
For a standardized language like SQL you don't have API incompatibility. Yet a cost based optimiser may break your application, completely. Calendar Versioning prompts to update and highlights that you should test the behaviour every time, which sounds about right. Also even a patch release of a SemVer library is allowed to be runtime incompatible. Throwing an exception on incorrect usage is down to the patch definition. It fixes incorrect (undefined) behaviour. Going from a O(1) to. O(n²) implementation to fix behaviour is also within SemVer patch level. SemVer does not guarantee that your code will continue to work as intended after an upgrade. It only guarantees you don't have to change your code between minor versions.

by mcdee 7y ago

djsumdog 7y ago

They also mention in the article how they don't support skipping releases, so it sounds like you have to upgrade to each point release anyway? Really if you're not constantly updating dependencies as part of your pipelines, you're going to quickly get into dependency rot issues.

web007 7y ago
I'm always surprised at how often developers freeze a set of versions and leave them for a lifetime. In my past three companies I have been the only one interested in pushing dependencies on a regular basis. I always start with a massive backlog, and end up having to incrementally update from the Stone Age to $today. Once that's set and tests pass it's easy to keep things up-to-date, you end up with single-digit changes every month instead of ~100 every year. Do it this way and save yourself the pain of zillions of updates when you HAVE to bump a package for a CVE.
- BurningFrog 7y ago
  Yet another case of "if it hurts, do it more often" https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
- njharman 7y ago
  Word! And same for me at new jobs. I also tend to be the one who writes docs, gets testing automated, CI. Too many developers think banging out code as fast as they can is "doing their job well".
- paulddraper 7y ago
  But the journey from A to B to C to D is longer than A to D. You can get whiplash from conforming to every change in the winds.
  - erik_seaberg 7y ago
    This. Skipping B and C needs to be managed like any other technical debt, but it can pay off. It's not your job to regression test every intermediate version of everyone's libraries.

lifthrasiir 7y ago

The problem of semver is that everyone interprets the compatibility differently. There are some language-supported criteria, but that does not cover all important use cases. In addition, any reasonable compatibility criteria might be impossible for large enough softwares---every revision can be potentially major in the semver terminology and it won't deliver much value to the user anyway. The calender versioning is useful for such cases.

sametmax 7y ago
I read that as "the problem with semver is it's not perfect". Well yeah. But no semver is worse: upgrading is hard enough when devs communicate on what breaks, but when they don't, it's just a nightmare. Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.
- lifthrasiir 7y ago
  I think the language-backed semver can be useful (I really want Cargo to support this mode!). The general unguided semver seems less useful. I envision a much simplified alternative (or analogue) to the semver: there is a single decimal revision, and you should strive to be compatible back to the first revision. When you are willing to break the compatibility, you simply rename. This is similar to Go's practice but can be technically made compatible to the three-part semver (by encoding minor and patch versions to the decimal).
  - lugg 7y ago
    This is my issue with semver. I don't care about minor non breaking change, just give me the latest. Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right? So lib: 1.* Should be fine, right? But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?
    - 7y ago

y0ghur7_xxx 7y ago

> The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations. No. Semver states quite clearly that "Major version MUST be incremented if any backwards incompatible changes are introduced to the public API.". It does NOT state that the Major verson MUST NOT be incremented if the api has no backwards incompatible changes. You can increment the MAJOR component of the version number at your will. So this is quit clearly a 3.0.0 release. Or it could be a 40.0.0 release and it would still be valid semver.

StavrosK 7y ago
By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.
- cormacrelf 7y ago
  Except that for it to remain both valid calver and valid semver, they would have to delay all breaking changes until January every time they come up.
  - StavrosK 7y ago
    They seem to indicate that they aren't expecting any more breaking changes, but yes, that's generally true.
- Legogris 7y ago
  It's not valid if 19.2 introduces breaking changes form 19.1
- trickstra 7y ago
  true, but doing that makes no sense, because people who made their software depend on major v18 are not switching automatically, because they first need to check if any breaking changes happened and if they need to modify their own software. Semver is "semantic" for a reason - to simplify this daunting task. Increasing major version even when there are no breaking changes is technically still semver, but without the helpful warranty, so it completely misses the point

simula67 7y ago

They could have picked Android's versioning scheme : a codename to signal significance and an API level to signal compatibility.

kibwen 7y ago
This right here. The only reason people observe tension between semantic versioning and romantic versioning is because prior to semantic versioning we spent decades conflating the version number to convey both "important new feature" and "incompatible changes". Both user marketing and technical compatibility guidance are important, but there's nothing that inherently says that both of these things need to be communicated via a single version number. Pick a nice-sounding word to market your version with big changes, and leave it unrelated to your API version.

NullPrefix 7y ago

>The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does. Old is bad, new is good. What else is there to understand?

username223 7y ago
"You now have Chrome/Firefox 277, which is different from version 276, and has installed itself. Deal with it, because there's no option to revert to version 276." That's just how software works these days.

treffer 7y ago

For a standardized language like SQL you don't have API incompatibility. Yet a cost based optimiser may break your application, completely. Calendar Versioning prompts to update and highlights that you should test the behaviour every time, which sounds about right. Also even a patch release of a SemVer library is allowed to be runtime incompatible. Throwing an exception on incorrect usage is down to the patch definition. It fixes incorrect (undefined) behaviour. Going from a O(1) to. O(n²) implementation to fix behaviour is also within SemVer patch level. SemVer does not guarantee that your code will continue to work as intended after an upgrade. It only guarantees you don't have to change your code between minor versions.