8 ms·

ZeroVer: 0-Based Versioning

102 points by dmitryminkovsky 3y ago

thatxliner 3y ago
I can’t tell if this is serious or satire. There’s no spec.
- netmare 3y ago
  It's obviously satirical. If so, the author is brilliant. Otherwise, well... I mean just look at the project show cases. Included are the usual colossal cluster^Wframeworks that power our decaying software infrastructure. Personally, I don't trust anything that either stays perpetually under v1.0 or exceeds v10-15.
  - jrockway 3y ago
    There's no point in calling it 1.0 unless you want to break compatibility with 0.x. Sometimes you get the design right on day 1, I guess.
    - Conscat 3y ago
      In SemVer, you can break compatibility with 0.x within 0.x. 1.x is the promise that there won't be any future compatibility breaks within the 1.x series.
  - deleted 3y ago
    [deleted]
  - joseluis 3y ago
    > exceeds v10-15 What do you think about internet browsers like Firefox and Chromium?
    - netmare 3y ago
      I find it ridiculous that Chrome, Edge and Firefox are all currently around v115. It's just a marketing term now. I've seen Firefox and Thunderbird major version numbers change for simple bugfixes. A release date would be enough.
- auggierose 3y ago
  It should be satire, but it is serious. The spec is SemVer, but only versions starting with a zero are allowed. This just shows that SemVer is bullshit.
  - r4indeer 3y ago
    It is satire. They want you to do SemVer (or CalVer, etc.) properly. There are arguments against SemVer, but I don't see how this one of them.
    - avgcorrection 3y ago
      The 0ver projects follow SemVer.
      - r4indeer 3y ago
        In a broad sense maybe, but not really. The spec says: > 4. Major version zero (0.y.z) is for initial development. I'd argue that most of the projects we are talking about here are long past initial development.
        avgcorrection 3y ago
        For sure. The problem though is that the strongest points of SemVer are the “machine-readable”, straightforward rules, in particular the rules about bumping the major version. But (like you note) SemVer also has this soft rules that goes beyond how to do versions and end up really dictating how a project should be done: 1. You should have a 0.x.x period for initial development 2. This is the not-stable part of the project lifecycle 3. After 1.x.x. you should be conservative about bumping the major version (not sure if this is from the specification webpage or if this is just the culture around SemVer though) Point 3 might be what keeps projects on 0ver. IMO SemVer itself (the culture around it can’t be controlled so that’s outside the domain of discourse) should have just dictated the machine-readable things. Thus points 1 and 2 are fine, but point 3 really discourages large major version integers. I guess some projects can’t realistically follow that. Not because the developers are bad necessarily but simply because breaking changes are part of the domain, more or less. It seems that only projects that end up reaching a low major version over, say, a decade, fit into the SemVer culture (meaning that people won’t complain about the versioning practice). Maybe some projects simply feel that they get less pushback if they stay on 0ver instead of going for 1.0.0 and then having to go up to 7.0.0 or beyond. A specification which only consists of three integers (plus the optional “beta”, “rc” appends) is inherently limited. Which is why it should be very limited in scope. SemVer should have just stuck to dictating the machine-readable part without having any opinions about how large the major version integer gets. (Again, maybe this is the culture around SemVer, not something from SemVer itself.) EDIT: Less verbosely: SemVer seems to both dictate the breaking change versioning as well as making infrequent major bumps after 0.x.x. I think that is an overreach if you want your specification to be focused and uncontroversial, because in practice people will end up going back and forth about tradeoffs. See also: https://news.ycombinator.com/item?id=28090144 https://news.ycombinator.com/item?id=28090144
- pseufaux 3y ago
  Satire, for sure. Check the about page. That said with the number of projects on this list, it might as well be serious.
- r4indeer 3y ago
  It's satire. If you're unsure, have a look at their about page [1]. They are criticising the idea of staying on a 0.x release for years even though your project is long used in production by now. [1] https://0ver.org/about.html https://0ver.org/about.html
- pwdisswordfishc 3y ago
  Satire can be serious. https://tvtropes.org/pmwiki/pmwiki.php/Main/SatireParodyPastiche https://tvtropes.org/pmwiki/pmwiki.php/Main/SatireParodyPast...
lamontcg 3y ago
Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.
- pictur 3y ago
  What are the horrible things about SemVer? Can you give details?
  - lifthrasiir 3y ago
    Semantic Versioning requires you to declare a public API, which is not even remotely possible for many projects. If the public API surface is clear semantic versioning does indeed work well, but otherwise it doesn't give much information as users have no idea what the public API would be. Calendar versioning [1] or even a single-number version is more preferred in such situations. [1] https://calver.org/ https://calver.org/
    - hnlmorg 3y ago
      Yes! Thank you. Exactly this :) Nearly every org I’ve worked in has used semver internally and nearly every time their version numbers were just incremented arbitrarily because there wasn’t an exposed API. This lead to countless problems, not least of all because semver usually requires one to manually set the version number based on the change log and people are generally pretty bad at changing point releases. So I’ve usually ended up changing the versioning scheme to build number (generated by the CI/CD tooling) plus some extra information like git hash and/or timestamp - depending on the application and whether that build information can be easily encoded as additional metadata or not.
      - clhodapp 3y ago
        In my opinion, Semver only makes sense for shared libraries, not for applications, or OSes, or for APIs exposed on the network. For applications, it goes just like you said. For APIs on the network, the caller should only get to control the breaking version their request gets routed to (the rest is abstractly owned by the service provider).
zetalyrae 3y ago
I noticed this the other day while writing a small server in Python. FastAPI is 0.100, fine. But I was surprised to find: - Uvicorn is 0.22 - httpx is 0.24 - starlette is 0.28 And so on and on. More generally, the quality of Python's tooling and ecosystem is astonishingly low compared to the investment that every day pours into it.
- nine_k 3y ago
  Astonishingly low compared to what? And in what aspects? (Asking unironically.)
  - zetalyrae 3y ago
    I use Rust professionally and even though it is a newer language with infinitely fewer developers and sponsoring organizations, the tooling and ecosystem is already superior. `cargo` is superior (in DX terms) to whatever nightmare is current in the Python world, `rust-analyzer` is better than to PyCharm, the ecosystem is smaller but more reliable.
    - r4indeer 3y ago
      I regularly hear that the tooling of Python is bad, but we've had Poetry for a while now and it just works. Unfortunately, I'm not experienced in Rust so I cannot really compare it to cargo. However, Poetry does everything I would expect from dependency management and packaging/publishing and I've never had problems with it. Also, there is ruff [2] (ironically written in Rust) and mypy [3] (they recently left 0ver!) for static analysis, black for code formatting (I really miss an opinionated formatter like this in other languages), etc. They also work just fine. Python tooling doesn't seem bad to me. [1] https://python-poetry.org/ https://python-poetry.org/ [2] https://github.com/astral-sh/ruff https://github.com/astral-sh/ruff [3] https://mypy-lang.org/ https://mypy-lang.org/
      - zetalyrae 3y ago
        I'll grant it could be much worse (Common Lisp, OCaml also have significant tooling problems). I haven't used mypy but I do use pyright and it's alright. The only way I've found to make Python tolerable is 1) lots of dataclasses and 2) using it as a more strongly-typed bash (i.e.: not for building large and complex software objects).
vbezhenar 3y ago
People just love LTS and backwards compatibility too much. I'm one of them. But it slows the industry, when you can't do API refactors and have to keep bad decisions forever. I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. Like new major version every year, deprecate API on the next major version, remove deprecated API on the following major version. So you have 1 year to rewrite your app if necessary. And supporting old versions for those enterprises who would rather pay than upgrade might be a good source of income.
- lifthrasiir 3y ago
  > I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of strictly obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the release in question. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict. [1] https://github.com/chronotope/chrono https://github.com/chronotope/chrono [2] https://github.com/chronotope/chrono/issues/146#issuecomment-309276715 https://github.com/chronotope/chrono/issues/146#issuecomment... [3] https://github.com/chronotope/chrono/issues/156 https://github.com/chronotope/chrono/issues/156 [4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#040-2017-06-22 https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...
  - chronogram 3y ago
    I understand from the author perspective that everything below 1.0 is subject to change, from the hobby user perspective I see 0.3 to 0.3.1 and think "oh bug fix, that means I won't read it" without expecting semver.
    - lifthrasiir 3y ago
      All those things happened when the Rust crate ecosystem was still much in flux (back in 2017), and I had some good reasons: - Serde had made a very slight but breaking change in 1.0, and at that time I think it was impossible to support both Serde 0.9 and 1.0 in a single crate without a hacky workaround (which I only learned much later). So if I had to pick only one version to support, it ought to be 1.0 as the change was trivial to resolve. - Cargo's use of semantic versioning is, while documented, not strictly conforming because 0.x.y is considered compatible with 0.x.z where x > 0 and y < z [1]. - People complained a lot when Chrono went 0.2.x to 0.3.0 as well. This is IMO the biggest reason to issue a breaking change; if people would complain in either way, I wanted to make a choice that benefits the whole Rust ecosystem more. If this happen today I would agree that I shouldn't have done that, but I think it was not that clear cut at that time. [1] https://semver.org/#spec-item-4 https://semver.org/#spec-item-4
quickthrower2 3y ago
While this is probably satire, I sort of agree with it! I always thought you just need two numbers, a.b You increment b when you change something in a backwards compatible way. You increment a when you make a breaking change. If you are used to semver, it is like ditching the minor version and calling it a patch. a.b is if course isomorphic to the 0.a.b system mentioned here. The disadvantage is downgrading patch-only in semver may now be breaking change in twover but that is a rare edge case IMO.
- conradludgate 3y ago
  It depends on the library. I personally like the minor vs patch distinction. If I see a patch version I might update immediately because I don't want a known bug in my application, but if I see a new minor feature version I might wait a bit
  - diarrhea 3y ago
    Same, but note a minor version encompasses all patches since the last release as well. You could have a single feature and countless bug fixes, but it will only show up as a meagre minor bump, with a suspicious zero in the patch field.
  - kzrdude 3y ago
    In theory the patch verison should be painless and always a given upgrade. The minor version might have at least the same number of important bug fixes, it's just coming with a different cost of having larger changes as well. Some fixes only come with larger changes. Like the recently posted rust regex 1.9 release. Only a rewrite of the library fixed some long-standing issues.
- zajio1am 3y ago
  > You increment b when you change something in a backwards compatible way. Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users. For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.
gybon 3y ago
I prefer negative versioning for prerelease software. It's like a countdown to when your project will be viable and ready to show to the world. Currently on version -2.-0.-61 of my social media network for dogs. It's getting there!
- return_to_monke 3y ago
  how do you know when it'llbe finished, before the fact?
- dontlaugh 3y ago
  That’s not entirely unlike LaTeX versions approaching pi.
megapatch 3y ago
Maybe it is time to consider INvers, irrational number versioning, as used in eg TeX https://en.m.wikipedia.org/wiki/TeX https://en.m.wikipedia.org/wiki/TeX In TeX the version approaches Pi, every new version adds a decimal. Elegant, will hold forever! TeX 3.141592653 is 45 years old. Its companion Metafont has version number 2.71828182, you can see where this is going.
- xigoi 3y ago
  Donald Knuth intentionally chose this versioning scheme to point out how much he trusts his software to never change.
Tempest1981 3y ago
Discussion in 2021: https://news.ycombinator.com/item?id=28154187 https://news.ycombinator.com/item?id=28154187
Culonavirus 3y ago
Ah yes, an ideal versioning scheme for modern video game projects!
mhitza 3y ago
Page should be updated, Terraform nowadays is in the 1.x version timeline.
avgcorrection 3y ago
This is a funny lampooning of SemVer. That’s at least how I choose to interpret it.
malkia 3y ago
best versioning is svn/p4/g4 monotonically increasing changelist/revision number
jonnycomputer 3y ago
I'm actually interested in practical examples of alternatives to Name+SemVer for (1) data analysis oriented code (2) code to run experiments (e.g. psych paradigms) I often find that in such code, forking is rather more common. That is, the code bases become wider rather than deeper. For example, we might run several experiments that have a strong resemblance to each other, but have any number of (experimentally relevant) tweaks. Within each fork, I rename, and restart the semantic versioning.
schmichael 3y ago
The purpose of versioning is to communicate something to your users. (It's also necessary to increase over time for package managers to work, but that's an easy bar to reach.) SemVer tries to explicitly define exactly what's being communicated: API compatibility. I think that's great, especially for libraries, but it's neither the whole story nor what's most meaningful for most projects. The most obvious and nefarious example is that the most severe and painful kinds of backward incompatibilities are superficially permissible under SemVer: behavior changes. To confuse the issue even more these behavior changes might be to fix a bug and restore the original or intended behavior of a feature! There's no single best way to communicate that to users through a version number: if libfoo v1.4.3 broke a behavior from 1.4.{0,1,2}, should the fix be in v1.4.4 or v1.5 because technically you're creating a backward incompatibility! Does the answer change if the buggy behavior has been around multiple patch releases or multiple minor releases? Does the scale of the behavior difference impact the versioning scheme chosen? Does the approximate number of users impacted impact the versioning scheme chosen? Probably! ZeroVer is, in my opinion, a hacky but fine solution to this: no guarantees! The developers just want to develop and it's up to the consumers of the project to figure out what release they want to use. ZeroVer is when a project chooses not to try to communicate very much through version numbers. I think that's often better than some strict adherence to SemVer that falls apart under any sort of reasonable scrutiny. I like how browsers have gone: basically give up on the traditional Major Version Number. A Chrome 2 or Firefox 2 that is a radical redesign would probably be an entirely new product with new branding and versions. So just bump the first number a lot to communicate feature releases to users, and bump the other numbers for basically internal build reasons. The minor, patch, and build numbers are free to be used and abused for a lot of complex purposes incredibly complex and popular projects like browsers (and operating systems) have. I think a lot of projects, Nomad included, would probably be best represented by BrowserVer. Nomad is deeply committed to incremental improvements and backward compatibility, so any "Nomad 2.0" efforts are more likely to happen under a new project. Frankly Nomad 1.0 was more about marketing than any sort of meaningful feature or compatibility promise: we wanted to communicate Nomad was stable and reliable. Going from 0.x -> 1.x is an easy way to communicate that even if nothing more significant happened from 0.12 -> 1.0 than had happened from any 0.X -> 0.Y.
- lamontcg 3y ago

thatxliner 3y ago

I can’t tell if this is serious or satire. There’s no spec.

netmare 3y ago
It's obviously satirical. If so, the author is brilliant. Otherwise, well... I mean just look at the project show cases. Included are the usual colossal cluster^Wframeworks that power our decaying software infrastructure. Personally, I don't trust anything that either stays perpetually under v1.0 or exceeds v10-15.
- jrockway 3y ago
  There's no point in calling it 1.0 unless you want to break compatibility with 0.x. Sometimes you get the design right on day 1, I guess.
  - Conscat 3y ago
    In SemVer, you can break compatibility with 0.x within 0.x. 1.x is the promise that there won't be any future compatibility breaks within the 1.x series.
- deleted 3y ago
  [deleted]
- joseluis 3y ago
  > exceeds v10-15 What do you think about internet browsers like Firefox and Chromium?
  - netmare 3y ago
    I find it ridiculous that Chrome, Edge and Firefox are all currently around v115. It's just a marketing term now. I've seen Firefox and Thunderbird major version numbers change for simple bugfixes. A release date would be enough.
auggierose 3y ago
It should be satire, but it is serious. The spec is SemVer, but only versions starting with a zero are allowed. This just shows that SemVer is bullshit.
- r4indeer 3y ago
  It is satire. They want you to do SemVer (or CalVer, etc.) properly. There are arguments against SemVer, but I don't see how this one of them.
  - avgcorrection 3y ago
    The 0ver projects follow SemVer.
    - r4indeer 3y ago
      In a broad sense maybe, but not really. The spec says: > 4. Major version zero (0.y.z) is for initial development. I'd argue that most of the projects we are talking about here are long past initial development.
      - avgcorrection 3y ago
        For sure. The problem though is that the strongest points of SemVer are the “machine-readable”, straightforward rules, in particular the rules about bumping the major version. But (like you note) SemVer also has this soft rules that goes beyond how to do versions and end up really dictating how a project should be done: 1. You should have a 0.x.x period for initial development 2. This is the not-stable part of the project lifecycle 3. After 1.x.x. you should be conservative about bumping the major version (not sure if this is from the specification webpage or if this is just the culture around SemVer though) Point 3 might be what keeps projects on 0ver. IMO SemVer itself (the culture around it can’t be controlled so that’s outside the domain of discourse) should have just dictated the machine-readable things. Thus points 1 and 2 are fine, but point 3 really discourages large major version integers. I guess some projects can’t realistically follow that. Not because the developers are bad necessarily but simply because breaking changes are part of the domain, more or less. It seems that only projects that end up reaching a low major version over, say, a decade, fit into the SemVer culture (meaning that people won’t complain about the versioning practice). Maybe some projects simply feel that they get less pushback if they stay on 0ver instead of going for 1.0.0 and then having to go up to 7.0.0 or beyond. A specification which only consists of three integers (plus the optional “beta”, “rc” appends) is inherently limited. Which is why it should be very limited in scope. SemVer should have just stuck to dictating the machine-readable part without having any opinions about how large the major version integer gets. (Again, maybe this is the culture around SemVer, not something from SemVer itself.) EDIT: Less verbosely: SemVer seems to both dictate the breaking change versioning as well as making infrequent major bumps after 0.x.x. I think that is an overreach if you want your specification to be focused and uncontroversial, because in practice people will end up going back and forth about tradeoffs. See also: https://news.ycombinator.com/item?id=28090144 https://news.ycombinator.com/item?id=28090144
pseufaux 3y ago
Satire, for sure. Check the about page. That said with the number of projects on this list, it might as well be serious.
r4indeer 3y ago
It's satire. If you're unsure, have a look at their about page [1]. They are criticising the idea of staying on a 0.x release for years even though your project is long used in production by now. [1] https://0ver.org/about.html https://0ver.org/about.html
pwdisswordfishc 3y ago
Satire can be serious. https://tvtropes.org/pmwiki/pmwiki.php/Main/SatireParodyPastiche https://tvtropes.org/pmwiki/pmwiki.php/Main/SatireParodyPast...

lamontcg 3y ago

Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.

pictur 3y ago
What are the horrible things about SemVer? Can you give details?
- lifthrasiir 3y ago
  Semantic Versioning requires you to declare a public API, which is not even remotely possible for many projects. If the public API surface is clear semantic versioning does indeed work well, but otherwise it doesn't give much information as users have no idea what the public API would be. Calendar versioning [1] or even a single-number version is more preferred in such situations. [1] https://calver.org/ https://calver.org/
  - hnlmorg 3y ago
    Yes! Thank you. Exactly this :) Nearly every org I’ve worked in has used semver internally and nearly every time their version numbers were just incremented arbitrarily because there wasn’t an exposed API. This lead to countless problems, not least of all because semver usually requires one to manually set the version number based on the change log and people are generally pretty bad at changing point releases. So I’ve usually ended up changing the versioning scheme to build number (generated by the CI/CD tooling) plus some extra information like git hash and/or timestamp - depending on the application and whether that build information can be easily encoded as additional metadata or not.
    - clhodapp 3y ago
      In my opinion, Semver only makes sense for shared libraries, not for applications, or OSes, or for APIs exposed on the network. For applications, it goes just like you said. For APIs on the network, the caller should only get to control the breaking version their request gets routed to (the rest is abstractly owned by the service provider).

zetalyrae 3y ago

I noticed this the other day while writing a small server in Python. FastAPI is 0.100, fine. But I was surprised to find: - Uvicorn is 0.22 - httpx is 0.24 - starlette is 0.28 And so on and on. More generally, the quality of Python's tooling and ecosystem is astonishingly low compared to the investment that every day pours into it.

nine_k 3y ago
Astonishingly low compared to what? And in what aspects? (Asking unironically.)
- zetalyrae 3y ago
  I use Rust professionally and even though it is a newer language with infinitely fewer developers and sponsoring organizations, the tooling and ecosystem is already superior. `cargo` is superior (in DX terms) to whatever nightmare is current in the Python world, `rust-analyzer` is better than to PyCharm, the ecosystem is smaller but more reliable.
  - r4indeer 3y ago
    I regularly hear that the tooling of Python is bad, but we've had Poetry for a while now and it just works. Unfortunately, I'm not experienced in Rust so I cannot really compare it to cargo. However, Poetry does everything I would expect from dependency management and packaging/publishing and I've never had problems with it. Also, there is ruff [2] (ironically written in Rust) and mypy [3] (they recently left 0ver!) for static analysis, black for code formatting (I really miss an opinionated formatter like this in other languages), etc. They also work just fine. Python tooling doesn't seem bad to me. [1] https://python-poetry.org/ https://python-poetry.org/ [2] https://github.com/astral-sh/ruff https://github.com/astral-sh/ruff [3] https://mypy-lang.org/ https://mypy-lang.org/
    - zetalyrae 3y ago
      I'll grant it could be much worse (Common Lisp, OCaml also have significant tooling problems). I haven't used mypy but I do use pyright and it's alright. The only way I've found to make Python tolerable is 1) lots of dataclasses and 2) using it as a more strongly-typed bash (i.e.: not for building large and complex software objects).

vbezhenar 3y ago

People just love LTS and backwards compatibility too much. I'm one of them. But it slows the industry, when you can't do API refactors and have to keep bad decisions forever. I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. Like new major version every year, deprecate API on the next major version, remove deprecated API on the following major version. So you have 1 year to rewrite your app if necessary. And supporting old versions for those enterprises who would rather pay than upgrade might be a good source of income.

lifthrasiir 3y ago
> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of strictly obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the release in question. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict. [1] https://github.com/chronotope/chrono https://github.com/chronotope/chrono [2] https://github.com/chronotope/chrono/issues/146#issuecomment-309276715 https://github.com/chronotope/chrono/issues/146#issuecomment... [3] https://github.com/chronotope/chrono/issues/156 https://github.com/chronotope/chrono/issues/156 [4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#040-2017-06-22 https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...
- chronogram 3y ago
  I understand from the author perspective that everything below 1.0 is subject to change, from the hobby user perspective I see 0.3 to 0.3.1 and think "oh bug fix, that means I won't read it" without expecting semver.
  - lifthrasiir 3y ago
    All those things happened when the Rust crate ecosystem was still much in flux (back in 2017), and I had some good reasons: - Serde had made a very slight but breaking change in 1.0, and at that time I think it was impossible to support both Serde 0.9 and 1.0 in a single crate without a hacky workaround (which I only learned much later). So if I had to pick only one version to support, it ought to be 1.0 as the change was trivial to resolve. - Cargo's use of semantic versioning is, while documented, not strictly conforming because 0.x.y is considered compatible with 0.x.z where x > 0 and y < z [1]. - People complained a lot when Chrono went 0.2.x to 0.3.0 as well. This is IMO the biggest reason to issue a breaking change; if people would complain in either way, I wanted to make a choice that benefits the whole Rust ecosystem more. If this happen today I would agree that I shouldn't have done that, but I think it was not that clear cut at that time. [1] https://semver.org/#spec-item-4 https://semver.org/#spec-item-4

quickthrower2 3y ago

While this is probably satire, I sort of agree with it! I always thought you just need two numbers, a.b You increment b when you change something in a backwards compatible way. You increment a when you make a breaking change. If you are used to semver, it is like ditching the minor version and calling it a patch. a.b is if course isomorphic to the 0.a.b system mentioned here. The disadvantage is downgrading patch-only in semver may now be breaking change in twover but that is a rare edge case IMO.

conradludgate 3y ago
It depends on the library. I personally like the minor vs patch distinction. If I see a patch version I might update immediately because I don't want a known bug in my application, but if I see a new minor feature version I might wait a bit
- diarrhea 3y ago
  Same, but note a minor version encompasses all patches since the last release as well. You could have a single feature and countless bug fixes, but it will only show up as a meagre minor bump, with a suspicious zero in the patch field.
- kzrdude 3y ago
  In theory the patch verison should be painless and always a given upgrade. The minor version might have at least the same number of important bug fixes, it's just coming with a different cost of having larger changes as well. Some fixes only come with larger changes. Like the recently posted rust regex 1.9 release. Only a rewrite of the library fixed some long-standing issues.
zajio1am 3y ago
> You increment b when you change something in a backwards compatible way. Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users. For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.

gybon 3y ago

I prefer negative versioning for prerelease software. It's like a countdown to when your project will be viable and ready to show to the world. Currently on version -2.-0.-61 of my social media network for dogs. It's getting there!

return_to_monke 3y ago
how do you know when it'llbe finished, before the fact?
dontlaugh 3y ago
That’s not entirely unlike LaTeX versions approaching pi.

megapatch 3y ago

Maybe it is time to consider INvers, irrational number versioning, as used in eg TeX https://en.m.wikipedia.org/wiki/TeX https://en.m.wikipedia.org/wiki/TeX In TeX the version approaches Pi, every new version adds a decimal. Elegant, will hold forever! TeX 3.141592653 is 45 years old. Its companion Metafont has version number 2.71828182, you can see where this is going.

xigoi 3y ago
Donald Knuth intentionally chose this versioning scheme to point out how much he trusts his software to never change.

Tempest1981 3y ago

Discussion in 2021: https://news.ycombinator.com/item?id=28154187 https://news.ycombinator.com/item?id=28154187

Culonavirus 3y ago

Ah yes, an ideal versioning scheme for modern video game projects!

mhitza 3y ago

Page should be updated, Terraform nowadays is in the 1.x version timeline.

avgcorrection 3y ago

This is a funny lampooning of SemVer. That’s at least how I choose to interpret it.

malkia 3y ago

best versioning is svn/p4/g4 monotonically increasing changelist/revision number

jonnycomputer 3y ago

I'm actually interested in practical examples of alternatives to Name+SemVer for (1) data analysis oriented code (2) code to run experiments (e.g. psych paradigms) I often find that in such code, forking is rather more common. That is, the code bases become wider rather than deeper. For example, we might run several experiments that have a strong resemblance to each other, but have any number of (experimentally relevant) tweaks. Within each fork, I rename, and restart the semantic versioning.

schmichael 3y ago

The purpose of versioning is to communicate something to your users. (It's also necessary to increase over time for package managers to work, but that's an easy bar to reach.) SemVer tries to explicitly define exactly what's being communicated: API compatibility. I think that's great, especially for libraries, but it's neither the whole story nor what's most meaningful for most projects. The most obvious and nefarious example is that the most severe and painful kinds of backward incompatibilities are superficially permissible under SemVer: behavior changes. To confuse the issue even more these behavior changes might be to fix a bug and restore the original or intended behavior of a feature! There's no single best way to communicate that to users through a version number: if libfoo v1.4.3 broke a behavior from 1.4.{0,1,2}, should the fix be in v1.4.4 or v1.5 because technically you're creating a backward incompatibility! Does the answer change if the buggy behavior has been around multiple patch releases or multiple minor releases? Does the scale of the behavior difference impact the versioning scheme chosen? Does the approximate number of users impacted impact the versioning scheme chosen? Probably! ZeroVer is, in my opinion, a hacky but fine solution to this: no guarantees! The developers just want to develop and it's up to the consumers of the project to figure out what release they want to use. ZeroVer is when a project chooses not to try to communicate very much through version numbers. I think that's often better than some strict adherence to SemVer that falls apart under any sort of reasonable scrutiny. I like how browsers have gone: basically give up on the traditional Major Version Number. A Chrome 2 or Firefox 2 that is a radical redesign would probably be an entirely new product with new branding and versions. So just bump the first number a lot to communicate feature releases to users, and bump the other numbers for basically internal build reasons. The minor, patch, and build numbers are free to be used and abused for a lot of complex purposes incredibly complex and popular projects like browsers (and operating systems) have. I think a lot of projects, Nomad included, would probably be best represented by BrowserVer. Nomad is deeply committed to incremental improvements and backward compatibility, so any "Nomad 2.0" efforts are more likely to happen under a new project. Frankly Nomad 1.0 was more about marketing than any sort of meaningful feature or compatibility promise: we wanted to communicate Nomad was stable and reliable. Going from 0.x -> 1.x is an easy way to communicate that even if nothing more significant happened from 0.12 -> 1.0 than had happened from any 0.X -> 0.Y.

lamontcg 3y ago