5 ms·

> There is no API nor ABI break in this version. I don’t know why, but this really, really bothers me. Why even use semver then?

by nusaru 4y ago

deleted 4y ago
[deleted]
Semaphor 4y ago
> Why even use semver then? They don’t?
- nusaru 4y ago
  Well yeah, but it looks like semver. Again, I don’t know why it bothers me, but it just... does.
  - justeleblanc 4y ago
    It's rather than semver looks like it. Curl predates semver by 15 years. People have been numbering their software release as $major.$minor.$patch forever.
  - avgcorrection 4y ago
    Oh yeah. The `x.y.z` notation that already existed and that SemVer just adopted is totally a surefire signal that “SemVer Here”. You’ve got the order of events all mixed up.
  - Semaphor 4y ago
    That’s a version number. Semver is a way of versioning. Now, saying "it bothers me that they don’t use semver" (which has them in the company of other small projects like typescript or the linux kernel) is a statement you can make, but "why use semver" when they don’t makes little sense.
    - nusaru 4y ago
      True. I could have phrased that better. I’ll take this as a sign to go to bed. Good night!
  - eesmith 4y ago
    Semver is a set of conventions on an older versioning scheme. The semver 1.0.0 spec (I think from 2010?) even points out: > This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. Thus, X.Y.Z does not automatically mean "semver". Nor does even X.0.0 mean semver. To give some 20th century counter-examples found through Google Scholar: "System Description: Spass Version 1.0.0" (1999) https://link.springer.com/chapter/10.1007/3-540-48660-7_34 https://link.springer.com/chapter/10.1007/3-540-48660-7_34 "This is version 2.0.0 of the software." (1999) https://econpapers.repec.org/software/bocbocode/s365703.htm https://econpapers.repec.org/software/bocbocode/s365703.htm "This report provides the NIKE3D user's manual update summary for changes made from version 3.0.0 April 24, 1995 to version 3.3.6 March 24, 2000" - https://www.osti.gov/servlets/purl/15004757 https://www.osti.gov/servlets/purl/15004757
eesmith 4y ago
The line before the one you quoted gives their explanation: "We decided it was about time to reset the minor number down to more a manageable level and doing it exactly on curl’s 25th birthday made it extra fun."
- nusaru 4y ago
  I read that too, but I feel like a project as widely used as curl should be more “conservative” in their version increments.
  - groestl 4y ago
    They really are: https://daniel.haxx.se/blog/2013/03/23/why-no-curl-8/ https://daniel.haxx.se/blog/2013/03/23/why-no-curl-8/
  - bawolff 4y ago
    Well linux incremented from 2 to 3 mostly because they felt like it, so they are in good company.
  - justeleblanc 4y ago
    Why? It's just a number.
  - ndsipa_pomu 4y ago
    Well, Windows jumped from 4.0 to 2000
    - DmitryOlshansky 4y ago
      Internally Windows 2000 was WinNT 5.0. The marketing name doesn’t have to reflect software versions.
groestl 4y ago
First: You should never trust semver anyways, not where it matters. Second: even in semver, you can bump all the way you want, especially the major version. Just don't skip bumping when you break stuff.
- 9dev 4y ago
  Being able to trust it is the entire raison d'être of semver. Everyone keeps complaining about it, but it's working splendid for hundreds of thousands of code bases.
  - groestl 4y ago
    It's best effort, and can make your life easier, but please treat it that way (best effort). For everything that matters, review and test even revision bumps.
    - 9dev 4y ago
      With third-party code, you're always relying on the best effort of others. Of course a version number doesn't relieve you of the need to run tests on your code base, but the probability for semver issues and code bugs should be about equally high - so there's no reason to trust one but not the other.
- huijzer 4y ago
  I think it can be okay in ecosystems where developers understand and respect semver
Slartie 4y ago
AFAIK, semantic versioning does not prohibit you from voluntarily increasing a version number at a more "important" place than the one you need to increase considering the changes you did. It just requires that you increase it if you do "hard" API/ABI changes that mandate an increase.
HeavyFeather 4y ago
Major instead of patch is far better than patch instead of major. Nothing breaks due to this new version.
fwlr 4y ago
Semver 2.0 on major version: “Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.” Curl on changes in 8.0.0: “There is only one actual “change” in this release. This is the first curl release to drop support for building on a systems that lack a working 64 bit data type. curl now requires that ‘long long‘ or an equivalent exists.” This is a backwards-incompatible breaking change, though not to the public API (but I believe semver as used is understood to include ABI, supported environments, etc), and it’s likely only “theoretically” breaking (are there any existing platforms that don’t have 64-bit support that did build curl, and now can’t? Looks like Daniel posed this question back in Sep 22 and found there were not https://curl.se/mail/lib-2022-09/0099.html https://curl.se/mail/lib-2022-09/0099.html). So semver is not respected to the letter (semver specifies that only public API matters), but it is respected in spirit (the breaking change is in supported build environments, which people do care about when picking versions), but it is also the smallest possible unit of change that still counts as a breaking change, so it’s a bit of a technicality as well. Personally I’m quite satisfied with it, it takes a decent understanding of semver to produce a case this finely balanced on the edge of two technicalities, which gives me the impression of being playful with semver rather than disrespecting, or being unaware of, semver. YMMV
- pdpi 4y ago
  > semver specifies that only public API matters People get really hung up on what is, or isn't "technically" a change to the API. "This now breaks the build" is a change to the public API in the only sense that matters.
- avgcorrection 4y ago
  > Personally I’m quite satisfied with it, it takes a decent understanding of semver to produce a case this finely balanced on the edge of two technicalities, which gives me the impression of being playful with semver rather than disrespecting, or being unaware of, semver. YMMV What? > > We decided it was about time to reset the minor number down to more a manageable level and doing it exactly on curl’s 25th birthday made it extra fun. There is no API nor ABI break in this version. Intentions-wise this has nothing to do with the Venerable SemVer.

> There is no API nor ABI break in this version. I don’t know why, but this really, really bothers me. Why even use semver then?

by nusaru 4y ago

> There is no API nor ABI break in this version. I don’t know why, but this really, really bothers me. Why even use semver then?

deleted 4y ago

[deleted]

Semaphor 4y ago

> Why even use semver then? They don’t?

nusaru 4y ago
Well yeah, but it looks like semver. Again, I don’t know why it bothers me, but it just... does.
- justeleblanc 4y ago
  It's rather than semver looks like it. Curl predates semver by 15 years. People have been numbering their software release as $major.$minor.$patch forever.
- avgcorrection 4y ago
  Oh yeah. The `x.y.z` notation that already existed and that SemVer just adopted is totally a surefire signal that “SemVer Here”. You’ve got the order of events all mixed up.
- Semaphor 4y ago
  That’s a version number. Semver is a way of versioning. Now, saying "it bothers me that they don’t use semver" (which has them in the company of other small projects like typescript or the linux kernel) is a statement you can make, but "why use semver" when they don’t makes little sense.
  - nusaru 4y ago
    True. I could have phrased that better. I’ll take this as a sign to go to bed. Good night!
- eesmith 4y ago
  Semver is a set of conventions on an older versioning scheme. The semver 1.0.0 spec (I think from 2010?) even points out: > This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. Thus, X.Y.Z does not automatically mean "semver". Nor does even X.0.0 mean semver. To give some 20th century counter-examples found through Google Scholar: "System Description: Spass Version 1.0.0" (1999) https://link.springer.com/chapter/10.1007/3-540-48660-7_34 https://link.springer.com/chapter/10.1007/3-540-48660-7_34 "This is version 2.0.0 of the software." (1999) https://econpapers.repec.org/software/bocbocode/s365703.htm https://econpapers.repec.org/software/bocbocode/s365703.htm "This report provides the NIKE3D user's manual update summary for changes made from version 3.0.0 April 24, 1995 to version 3.3.6 March 24, 2000" - https://www.osti.gov/servlets/purl/15004757 https://www.osti.gov/servlets/purl/15004757

eesmith 4y ago

The line before the one you quoted gives their explanation: "We decided it was about time to reset the minor number down to more a manageable level and doing it exactly on curl’s 25th birthday made it extra fun."

nusaru 4y ago
I read that too, but I feel like a project as widely used as curl should be more “conservative” in their version increments.
- groestl 4y ago
  They really are: https://daniel.haxx.se/blog/2013/03/23/why-no-curl-8/ https://daniel.haxx.se/blog/2013/03/23/why-no-curl-8/
- bawolff 4y ago
  Well linux incremented from 2 to 3 mostly because they felt like it, so they are in good company.
- justeleblanc 4y ago
  Why? It's just a number.
- ndsipa_pomu 4y ago
  Well, Windows jumped from 4.0 to 2000
  - DmitryOlshansky 4y ago
    Internally Windows 2000 was WinNT 5.0. The marketing name doesn’t have to reflect software versions.

groestl 4y ago

First: You should never trust semver anyways, not where it matters. Second: even in semver, you can bump all the way you want, especially the major version. Just don't skip bumping when you break stuff.

9dev 4y ago
Being able to trust it is the entire raison d'être of semver. Everyone keeps complaining about it, but it's working splendid for hundreds of thousands of code bases.
- groestl 4y ago
  It's best effort, and can make your life easier, but please treat it that way (best effort). For everything that matters, review and test even revision bumps.
  - 9dev 4y ago
    With third-party code, you're always relying on the best effort of others. Of course a version number doesn't relieve you of the need to run tests on your code base, but the probability for semver issues and code bugs should be about equally high - so there's no reason to trust one but not the other.
huijzer 4y ago
I think it can be okay in ecosystems where developers understand and respect semver

Slartie 4y ago

AFAIK, semantic versioning does not prohibit you from voluntarily increasing a version number at a more "important" place than the one you need to increase considering the changes you did. It just requires that you increase it if you do "hard" API/ABI changes that mandate an increase.

HeavyFeather 4y ago

Major instead of patch is far better than patch instead of major. Nothing breaks due to this new version.

fwlr 4y ago

Semver 2.0 on major version: “Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.” Curl on changes in 8.0.0: “There is only one actual “change” in this release. This is the first curl release to drop support for building on a systems that lack a working 64 bit data type. curl now requires that ‘long long‘ or an equivalent exists.” This is a backwards-incompatible breaking change, though not to the public API (but I believe semver as used is understood to include ABI, supported environments, etc), and it’s likely only “theoretically” breaking (are there any existing platforms that don’t have 64-bit support that did build curl, and now can’t? Looks like Daniel posed this question back in Sep 22 and found there were not https://curl.se/mail/lib-2022-09/0099.html https://curl.se/mail/lib-2022-09/0099.html). So semver is not respected to the letter (semver specifies that only public API matters), but it is respected in spirit (the breaking change is in supported build environments, which people do care about when picking versions), but it is also the smallest possible unit of change that still counts as a breaking change, so it’s a bit of a technicality as well. Personally I’m quite satisfied with it, it takes a decent understanding of semver to produce a case this finely balanced on the edge of two technicalities, which gives me the impression of being playful with semver rather than disrespecting, or being unaware of, semver. YMMV

pdpi 4y ago
> semver specifies that only public API matters People get really hung up on what is, or isn't "technically" a change to the API. "This now breaks the build" is a change to the public API in the only sense that matters.
avgcorrection 4y ago
> Personally I’m quite satisfied with it, it takes a decent understanding of semver to produce a case this finely balanced on the edge of two technicalities, which gives me the impression of being playful with semver rather than disrespecting, or being unaware of, semver. YMMV What? > > We decided it was about time to reset the minor number down to more a manageable level and doing it exactly on curl’s 25th birthday made it extra fun. There is no API nor ABI break in this version. Intentions-wise this has nothing to do with the Venerable SemVer.