4 ms·

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...

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...