19 ms·

ZeroVer: 0-Based Versioning

570 points by polm23 5y ago

what556 5y ago
This is being sold as "Cutting-edge software versioning for minimalist" but requires you to have an additional number in your version that does nothing
- quickthrower2 5y ago
  It’s like saying the UTF BOM does nothing. The 0. prefix tells you it’s an enlightened project.
deleted 5y ago
[deleted]
Errik 5y ago
I've to admit it: I read through it with increasing disbelief, feeling old and outdated, until I've reached the release date.
StephenJGL 5y ago
I love the religious overtones on the post. All I can say is that the best option is probably to coexist.
robertlagrant 5y ago
Here's something that's not zero: the number of comments from people that don't get the joke.
- rojoroboto 5y ago
  this is my favorite comment.
- tonyedgecombe 5y ago
  Humour is wasted on Hacker News.
kasperni 5y ago
ZeroVer is satire [1]. [1] https://0ver.org/about.html https://0ver.org/about.html
- ycuser2 5y ago
  Thank you... I couldn't understand the reason to use it.
  - mjburgess 5y ago
    It's so you can tell your users that the bugs aren't going to be fixed yet. It'll be ready by v1.
    - joshxyz 5y ago
      and you can break the api anytime
    - jeltz 5y ago
      I would say that it is more about avoiding to promise anything about API stability between versions.
- inanutshellus 5y ago
  ...and so it's explicit... the homepage's table of projects is a Wall of Shame.
toabi 5y ago
But hey… even terraform made it to v1.0.0 after some time… https://github.com/hashicorp/terraform/releases/tag/v1.0.0 https://github.com/hashicorp/terraform/releases/tag/v1.0.0
- andsens 5y ago
  ... and they geared up for it by releasing two breaking versions in the year leading up to v1.0.0. I managed to catch the entire upgrade path from 0.11 to 0.12 to 0.13 to 0.15. Good times.
  - bavell 5y ago
    It was so fun reinstalling old terraform versions so I could unfuck my cluster infra... not to mention the joy of finding they removed the .13->.14 migration command in .14 so you have to roll alllll the way back... Good times indeed.
eurasiantiger 5y ago
Shenanigans aside, 0.x versioning is commonly used when developers cannot (yet) make any guarantees about backwards compatibility between minor releases.
- dilap 5y ago
  At the risk of sucking the fun out of a pretty funny joke, I think the underlying subtext is that established projects are failing to "grow up" -- i.e., that established, depended-on projects are hiding under the shield shield of a youthful 0.x version, when really, given how popular, old, and depended-on they are, they should embrace that responsibility and grow into 1.something. (Though, on the other hand, maybe it's more just honest signaling of expectations. "We are a 0.x project, we value developer speed and a clean code-base more than backcompat or stability for users. We will NEVER grow up!" We could call it Peter Pan versioning.)
  - eurasiantiger 5y ago
    I’d hazard a guess that many of those projects are for environments that cannot guarantee stability, so the instability kind of rolls over to the projects themselves.
  - robertlagrant 5y ago
    I think they just don't care about marketing. 1.0 being grown up is a marketing perspective. You could start at 2.0 and not be "grown up" in the slightest.
    - inanutshellus 5y ago
      This is an unhelpful argument. It effectively says "meaning doesn't exist". I could also version my software "chicken.banana.guacamole" and be pissed that nobody understood that meant it was enterprise-and-production-ready. Point is, there's a convention and this satire website is pointing out obviously-wrong cases of mis-versioning.
      - 5y ago
necovek 5y ago
I did not find it a very compelling joke until I checked out the list of projects: some running their "0.*" versions for 10+ years, and many a familiar name in there too — ouch! That made me laugh out hard :D
soraminazuki 5y ago
Neovim is listed as a "notable ZeroVer project" and yet it has a 1.0(!!) milestone in the GitHub project page. https://github.com/neovim/neovim/milestones https://github.com/neovim/neovim/milestones
- colonwqbang 5y ago
  > 0% complete > No due date > Last updated over two years ago Looks like a classic case of ZeroVer!
  - quickthrower2 5y ago
    Replace “case” with “practitioner” please. It’s not a disease!
    - jrochkind1 5y ago
      Are you sure about that?
mjburgess 5y ago
Seemed like a strange joke until you see the table, Project Stars Released Releases Current Version 0ver years React Native 96,747 2015 359 0.65.0-rc.2 (2021) 6.3 ...lol God forbid tor, sklearn, react-native release a v1 -- people might expect things!
- k__ 5y ago
  Many OSS projects were and still are pre 1.0 for years. I think, it's a sign of hybris if a project owner goes 1.0 too soon.
  - julianlam 5y ago
    ... hubris? I think that's a bit much. We went v1 once we decided our software was ready for other people to use. It meant we'd ensure compatibility via upgrade scripts, and it meant we wouldn't do irresponsible things like tell users "this release requires you to drop your database and start over"
    - k__ 5y ago
      I think, that's the main problem with SemVer. Everyone tries to merge the major version with some kind of nebulous "readiness". While it should just be a number related to technical aspects of the software.
    - superjan 5y ago
      And I think that is the right way to think about it. I think people stay on 0 because they think they have to implement all ideas and edgecases before it you can call it 1.0. You can also get stuck on 1.x releases in the same way (notably Java).
  - mytailorisrich 5y ago
    If you have a set of working, useful features, however small as long as they part of your core product, and you release to the public then you have your v1.0. IMHO, if you stay pre 1.0 for years across many releases it means you have too wide a scope for what v1.0 should be. Essentially, your MVP is v1.0 since that the first viable product you release. But what sometimes happens is that people imagine v1.0 as being the full vision with everything and so they never really reach it. And of course sometimes it seems that there is no sensible explanation at all for why a product is still pre 1.0 to the point of being ripe for satire, indeed (and ZeroVer is really on point the way it satirises this!).
jokoon 5y ago
using the an ISO date with a release/beta/branch-name as a version number always make more sense to me...
- eurasiantiger 5y ago
  Proper semantic versioning gives you certain guarantees. Consider you’re on v1.2.1 of some package, pinned to your requirements as ”^1.2.1”. A security issue gets fixed, v1.2.2 is released, your CI/CD can manage this upgrade automatically. A new feature is introduced, v1.3.0 is released, your CI/CD can still manage this upgrade automatically. Developers know that there are new features because the minor version was incremented. But then, some core API refactoring is done to support new integrations, which happens to break backwards compatibility. Now, v2.0.0 is released, and it is obvious to developers that something major has changed. Your CI/CD does not do this upgrade automatically.
  - kashug 5y ago
    we tried semantic versioning for some time, but gave up. It is still people writing the code - and people do mistakes. So even when something is released as a patch how do we know that it was a mistake and it should have been a minor or a major version. Or they introduced a bug that would break our system? So in the end we would still end up not trusting it and rely on testing (hopefully as automatic as possible) before we could merge the upgrade. In the end we just switched to using timestamp-based version numbers and just try to upgrade often enough so each incremental change is small. And try to have good automatic tests that can do most of the regression testing for us.
    - jeltz 5y ago
      Miatakes happen but as an end user of a library I prefer having semantic versioning giving me a hint on where it is likely there is an API breakage and where there is unlikely to be one. I still use lock files, read release notes and test but knowing where things are likely to break saves me time.
dmos62 5y ago
> Low in the stack, low in the version. That's the HashiCorp way. > Most experts have come to agree, for all their complexity and absurdity, Kafka's writings have been influential, despite the prevalence of bugs. I'm loving this.
- khanan 5y ago
  Too bad the "article" is written in 2018 and Hashicorp release Vault 1.0.0 December 3rd, 2018 :)
  - Sebb767 5y ago
    It seems HashiCorp got the message ;)
  - nonameiguess 5y ago
    It actually has Vault, Terraform, and Nomad in the Projects Emeriti section at the bottom. They just never edited the original article. It appears Inkscape was the longest holdout, and went 19.7 years before finally releasing 1.0, though that's only of projects that did make the cutover. Some chemical process modeling software out of CMU called "Ascend" has been proudly avoiding 1.0 since 1978. I'm not sure how to get it as their website no longer seems to work, but apparently they were part of Google Summer of Code five times.
- smsm42 5y ago
  Kafka part is brilliant, too bad they went to the dark side with 1.0 release in 2017.
gHosts 5y ago
I wish I was joking. But our versioning scheme doesn't include zero. Not even for minor version numbers. As we (rightly) believe our customers don't trust them (for good reasons).
- ThePadawan 5y ago
  All humans are weird. If you're not used to reading version numbers, you'd be surprised that 1.10 comes after 1.9 and vice versa.
  - blueflow 5y ago
    Only in the US, the rest of the world also uses this format for dates: 1.10 is 1st october and 1.9 is first september.
    - Joker_vD 5y ago
      Even in the US format, the 10th of January is still after the 9th of January. Perhaps the correct sentiment would be "If you're not used to reading, you'd be surprised that 1.10 comes after 1.9 and vice versa".
      - ThePadawan 5y ago
        I have no idea how you or your parent immediately arrived at calendar dates (which in my book require a period at the end), but to everyone i know, 1.10 is not a date, but a floating point number with the same magnitude as 1.1, which is thus closer to 0 than 1.9 is.
        blueflow 5y ago
        How would October 1st be written down at your place?
        ThePadawan 5y ago
styren 5y ago
Obviously they've gotten a lot of inspiration from my favorite: Sentimental Versioning http://sentimentalversioning.org http://sentimentalversioning.org
jabiko 5y ago
Helmfile might be a good addition to the list: https://github.com/roboll/helmfile/releases/ https://github.com/roboll/helmfile/releases/
quickthrower2 5y ago
The best versioning is the one you already have and use every day. It is right under your nose. You probably typed or pasted one or these special version strings in today or you will later. Or you sent one to a colleague in a slack message this week most certainly. It is of course the git commit hash! Suck all meaning out of your version by using the commit hash. Never worry about which digit to increment (semver, 0ver) or what date it is (calver) because who remembers the date. Also has the advantage that it’s easy to check out the source code for a version! Use git log and pipe that to a file in /var/www and you have release notes with the version numbers!
- BiteCode_dev 5y ago
  Really handy to communicate verbaly or promote.
  - wraptile 5y ago
    You just keep appending spaces until commit hash sounds human! Check out latest release: h0rs35l0v3b4tt3ry4cid5! Eventually people will start random commits like "random commit to change hash" when commits accidently result in racist or taboo terms lol
- ricardobeat 5y ago
  And have no idea how recent the version is unless you have immediate access to git. It’s a very engineer-centric idea.
- choeger 5y ago
  If that's not sarcasm, and I am really not sure whether it is, just one counter argument: commit hashs are not ordered and they can change.
  - account42 5y ago
    > they can change This is incorrect. You can create a new commit with a different hash, but the commit hash being a checksum of the commit contents will never change for the same commit.
reckoner22 5y ago
An alternative would be to introduce a „marketing version „number independent of the semver version. Usually there are packages with big api differences for the first 3 versions or so. The major version number is used to discuss bugs, development, etc. New versions usually entail a beta period that results in two active versions for a while. This would allow the major version to be used more often for breaking changes to help with automated dependency update tools.
- jeltz 5y ago
  PoatgreSQL used to do this and they abandoned it for good reasons. Too much bikesheddinr about when the marketing number should be incremrnted and too many confused users who (with good reason) thought the marketing number actually meant something.
bungle 5y ago
True ancestor to this: https://en.m.wikipedia.org/wiki/Enlightenment_(software) https://en.m.wikipedia.org/wiki/Enlightenment_(software) ” The first version of Enlightenment was released by Rasterman (Carsten Haitzler) in 1997.[5] Version 0.17, also referred to as E17, was in development for 12 years starting in December 2000[6] until 21 December 2012 when it was officially released as stable.”
- jiggawatts 5y ago
  That brings back some memories! Back in '98 or '99, I ran into Carsten at UNSW and started talking to him because I thought it was cool how he used roller blades to go between classes. He set up my Linux login with Enlightenment before many people had even heard of it. My fellow students in the same year were using some hideous black & white (not even greyscale!) window manager, meanwhile I had this awesome colourful setup that felt like it was from the future. Fun times...
twobitshifter 5y ago
Having worked at a place with 11+ years of a project in ZeroVer, I would caution against ZeroVer as it can mentally wear on software developers. The 0. is not something embraced, but a taunting God who takes pleasure in suffering. The followers of ZeroVer all believe that with some combination of magic and hard work a 0. will turn to a 1., but the mighty 0. never rolls over. To topple the 0., they will try tricks like a full rewrite of core code, new scrum patterns, new directors of software development, more code reviews, iron clad specifications, testing specialists, and more. They’ll try to do things they see 1.0 software doing: sell the code, use it in production, make billion dollar decision based on its output, have entire livelihoods wrapped up in its existence, and still the 0. is unchanged. The myths of a roadmap to 1.0 will build over time, some say it’s always existed, but there’s no sign of a road or even civilization when you look around. The ZeroVer faith says that everyone is always on the road to 1.0 if they believe, but outsiders continually taunt them for not knowing when 1.0 will reveal itself.
- arcatek 5y ago
  I know you're joking, but I worked in a startup where a massive effort was made to completely rebuild the 1.x website - both backend and frontend. It required a lot of work from everyone, and I remember we even stayed late more than a few times to bring it to finish line. So it was a bit disheartening that the founders never bumped the version to 2.x once the rollout was achieved. It's perhaps a bit nitpicky, but it felt like the work wasn't properly appreciated.
  - koheripbal 5y ago
    Maybe I'm aged, but I always just use the date. If I build today, the version will just be 210811.1 and it updates automatically in each build. I'm a one man shop though so I never branch for major/minor releases.
    - tonyhb 5y ago
      This is the exact strategy we use for our rollouts too. 2021-08-12.01 was just released.
makach 5y ago
...wait, this is a joke?! ..right? *edit: yes, published 1 april 2018
lloydatkinson 5y ago
Is this a joke or a real site? How does basically putting a 0. in front of every version solve anything?
- keithnz 5y ago
  a joke and a not so subtle prod at all these long running projects that are stil 0.something
matsemann 5y ago
I always bump major even though we follow semver. I consider my contributions major no matter how small. No impostor syndrome here, sir. (/s)
lugged 5y ago
I remember when you might worry about getting fired using alpha version code in production.
pbhjpbhj 5y ago
Inkscape is a notable 0ver user until a recent lapse! I'm still on 0.9... , for, y'know, religious reasons. 18 years on a 0ver is hard to quit! (Seriously, I'm not sure the 1.0 is in the Kubuntu repos for my version). https://launchpad.net/inkscape/+milestone/1.0 https://launchpad.net/inkscape/+milestone/1.0
allo37 5y ago
I feel like this is meant to be satire, but I wonder if there's some truth to it: Usually updates to a "major" version come with an implied assumption that there won't be any breaking API changes. Maybe being perpetually at 0 gives you the "It's beta software, you need to update bro" defence against maintaining a stable API, and all the extra overhead that comes with it.
- a3w 5y ago
  Why not release 2.x after a month, breaking the API again? Heck, why not next day when you find out that all APIs suck.
  - allo37 5y ago
    Because you'll still have customers on version 1.x, who will still expect support and refuse to update for <reasons>. It's not that it's impossible but it imposes an additional burden on the development team, which affects how fast you can add features.
    - mahkoh 5y ago
      That's why our team at GigaCorp has switched to not using minor version numbers. In the past we had customers who expected continuous security updates without updates to the minor version due to some internal policy. All of our new products use 0.0.x versioning where x is incremented for each release. This way we can easily push out new releases and our customers have no reason to delay updates.
    - remram 5y ago
      But that's the same with 0.1 and 0.2. You will still have users in 0.1 who will expect support and refuse to update.
      - allo37 5y ago
        Unfortunately irrationally difficult customers are a bit like death and taxes in that sense, but "We have a new version with some minor fixes that you can use" is generally an easier sell than "We have a new version with some major changes that will completely disrupt your workflow".
amarant 5y ago
So why is react native still 0.x? Is it really still unstable after 6 years? Seems like they should settle on a API already...
hnlmorg 5y ago
> To drive the point home, even further down the stack, HashiCorp's Terraform also complies with ZeroVer's cutting-edge versioning scheme. With Vault and Terraform, HashiCorp demonstrates industry recognition of the importance of ZeroVer in infrastructure. Both of these have seen 1.x releases.
- inanutshellus 5y ago
  Page was made April 1st, 2018, so that's probably just bitrot. That said, I like to think they did 1.x releases specifically because they were hoping to get off this Wall of Shame.
hyperman1 5y ago
WindowMaker! I remember using it at the end of the 90s, thinking: It is fine. Just go to 1.0 already. Yet here we are, 20 years later.
404mm 5y ago
It’s borderline comical to read such strong opinions about how to version your software. “One shall not speak of 1.0!” (Not an actual quote). If 0ver works for your use case, go with it, by all means. It’s sortable (“nat-sortable” to be more precise) and it will get the job done. And so are many other versioning schemes. Think about your release cadency, how will you release new versions, patches and fixes and then pick one that makes sense to both humans and your code.
- shawxe 5y ago
  I'm pretty sure the page is supposed to be satirical. It's poking fun at the number of software projects that have been around for several years (or maybe even a couple of decades), have had dozens to hundreds of releases, and yet are somehow still at major version 0, which flies in the face of both semantic versioning and general common sense.
  - 404mm 5y ago
    Wow, lol. I usually pick up on satire. It’s just …it’s 2020-ish and it looked very aligned with various edgy opinions.
jrochkind1 5y ago
This is sarcastic/satire, pretty sure? Not sure all the comments are catching that. When I have to use a 0.x-versioned package because it's a (hard or soft) dependency of some popular framework/platform/tool that "everyone" is using... I feel personally insulted. Like they're saying "no, we're not willing to say this is production-ready, we're not willing to say that we're not going to break backwards compatibility every month or so in a way you can't predict from the version number so can't do automated dependency updates ever, but, hey, everyone else is using it, what's your problem?" It's like the ultimate embrace of the typical HN "open source maintainers owe you nothing and you should expect nothing of them" argument. Which is true, but if all packages literally made no effort to meet user needs and we had learned to expect nothing from them, we would never be using open source....
- vitro 5y ago
  From the About page: > ZeroVer is satire, please do not use it.
  - smsm42 5y ago
    Unfortunately, from the main page it's clear everybody does anyway.
- JadeNB 5y ago
  > When I have to use a 0.x-versioned package because it's a (hard or soft) dependency of some popular framework/platform/tool that "everyone" is using... I feel personally insulted. Like they're saying "no, we're not willing to say this is production-ready, we're not willing to say that we're not going to break backwards compatibility every month or so in a way you can't predict from the version number so can't do automated dependency updates ever, but, hey, everyone else is using it, what's your problem?" Wait, insulted by whom? The package developers are surely not obliged to develop their package to a standard that satisfies you, and it's hardly their fault if someone else feels that their package is useful enough to integrate it into something popular. Insulted by the popular framework that uses it … maybe, but you are not willing to forgo the use of 0.x-versioned packages even when it is a point of principle for you, so why should the developers of those frameworks forgo it when it is not a point of principle for them?
altcognito 5y ago
ElasticSearch was pretty solid when it was under zerover
deleted 5y ago
[deleted]
WaitWaitWha 5y ago
0. versioning sits on the throne of lies. The major and minor versioning continues within 0ver, just prepended with 0. As @twobitshifter (facetiously?) & @arcatek wrote, it messes negatively with the minds of developers. And, for decades we have been training non-technologists 0. is not production, 1. is better than 0., and 2. is better than 1.
everyone 5y ago
Oh its a joke? Poe's law was in effect for me.
jl6 5y ago
It’s a joke at the expense of projects whose developers have no idea when their own software will be finished. You can’t ever get to version 1 if you have no clear goal or sense of what being done means. The idea of requirements is now thoroughly out of fashion. And I suspect that a lot of projects stay hazy on their purpose in order to keep the door open for a pivot to the latest trendy concept, or an acquihire.
- dhagz 5y ago
  I'm going to be pedantic and say the idea of fixed requirements is out of fashion. The software I write has requirements, but they change about 1/3 of the way through each sprint.
ziml77 5y ago
I hate that so many projects don't ever move to version 1. It makes it hard to choose to use them for anything serious because 0.x implies that the developers don't think the project is ready yet. I think the reason projects get stuck at 0.x is because of interface stability expectations. When you're at version 0, you have the freedom to realize you made a bad choice and break interfaces to improve it in the long run. It's nice to know you have that freedom and that you're not committing to maintaining something in a state that is painful to work with.
- another-dave 5y ago
  Semver also allows you to make breaking changes at anytime with the bump from one major version to the next — e.g. if you look at something like RxJava they use semver well in this way & don't shy away from breaking changes to deprecate and tidy the API. If anything I think perpetual v0 dilutes the concept as gets people used to projects being stable at v0 rather than considering them alpha
smcameron 5y ago
Heh, my hobby project has been at version 0.1 since 2012 I think. But it's ok, because I've made no releases (it only runs on linux, and you have to compile it yourself. I find this keeps the quality of users, bug reports, complaints, etc. higher and the numbers lower). And also, it's a silly space game, so nobody cares anyway. And the really important thing to version is the network protocol it uses, currently at 53. The "versions" of the software are really the git commits. I try really hard to ensure every commit is viable (so that git bisect works, and so the top of the tree always works).
ziggus 5y ago
My versioning scheme is based on UNIX timestamps of releases, all concatenated together. Something like this: {major release timestamp}.{minor release timestamp}.{last patch timestamp}, which winds up like: 1542051468.1576431468.1613410668 Very clear and easy for users to understand.
lmilcin 5y ago
I believe that after half a dozen releases 0 stops being meaningful and is just reflection on somebody's inability to make a decision. I make my point by always numbering my first prod release as 1.0.0. It is never going to be perfect and it is always going to be in state of flux. Why try to push responsibility onto client by telling them "Guys, we have warned you, this is still version 0"?
Agentlien 5y ago
I enjoyed this. It was funny and had some really good jabs at some of these projects. I'm also happy that its list of notable ZeroVer projects includes Dwarf Fortress, currently at v0.47.05, 15 years after the first version was released.
MauranKilom 5y ago
Looks like fail2ban (16.8 years of being zero-versioned according to this site) is actually on the path to a 1.0 release: https://github.com/fail2ban/fail2ban/commit/3f5c382a988bb21f48a0fe3a26c2433d04f7076f https://github.com/fail2ban/fail2ban/commit/3f5c382a988bb21f... Well, the master branch is considered 1.0 at least. Not sure if there's been an official 1.0 release though...
dathinab 5y ago
The fear of not releasing 1.0 because of some strange believes that you can't release 2.0, 3.0 or 2364.0 or that 1.0 needs to be special in some way is really annoying. The moment your software is production ready it should not take long until you use major version numbers. If you are afraid of users expecting no change breaking after 1.0 don't stay below it as the user also expects 1.0. instead brake expectations by avoiding 1.0 and 2.0 specifically. E.g. jump from 0.69.0 to 69.0.0 or some other arbitrary number like 42.0.
exabrial 5y ago
If it really bothers you, I could write a script that subtracts 1 from semver compatible version numbers on checkout, and increments on push.
keiferkif 5y ago
I was ready to lose it on what I perceived as more pretentious developer shit, then I realized it was satire thank the Ford.
devy 5y ago
This blog post titled "ZeroVer: 0-based Versioning" was originally written on April 1, 2018, even though the "Notable ZeroVer Projects" section seems to be updated and current for this year. The canonical URL is https://0ver.org/zerover_0_based_versioning.html https://0ver.org/zerover_0_based_versioning.html The entire site only has a single blog post. Go figure.
snicker7 5y ago
A brutal admission that modern software is broken and that stability, predictability, and correctness is just too much to ask for.
david927 5y ago
I know it's all in jest but this bothered me: > Franz Kafka, who lived as an author in turn-of-the-20th-century Austria Kafka lived his whole life in Prague, Czech Republic. Yes, it was at the time within the borders of the Austrian-Hungarian Empire, but calling him Austrian is irksome.
- wott 5y ago
  > Kafka lived his whole life in Prague, Czech Republic. Kafka had been dead for 70 years when Czech Republic came to existence. He even lived only a handful of years in Czechoslovakia since he died young. So saying he lived most of his life in Austria is more correct, than assigning him to an entity which didn't exist at all at the time.
  - david927 5y ago
    Nope. You can say Austrian Hungarian Empire or better, Prague. He, and the people of the time, would not say they lived in Austria -- which didn't exist either. The people of the area spoke Czech. You can't shorten the Austrian Hungarian Empire to Austria or Hungary. It's both lazy and wrong. Also, the Czechs fought hard for their independence and achieved it during Kafka's lifetime. In the same way, literally no one says, "George Washington, Ben Franklin and Thomas Jefferson, who lived in 18th-century England..." We don't call them English, despite having been born in a colony of England, because they identified themselves as American and were officially recognized as that in their lifetime.
  - kzrdude 5y ago
    Compare to someone like George Washington. He grew up in the british empire, in their territory. That's the fact, yet it sounds wrong to call him british.
mbfg 5y ago
Our teams fully embrace ZeroVer versioning. Since we all agree ZeroVer versioning is superior, we have dropped the leading zero from our version numbers and know that is just implied to be there. We are all happy and rejoice!
travisgriggs 5y ago
ZeroVer is obviously satire, but doesn't it just demonstrate that "Semantic Versioning" works great as a theory, but struggles to keep up with the nuances of the real world? I have multiple sub components of our system that are effectively ZeroVer, not because I love zero ver at all, but because basically a simple linear integer would have worked, so I just let the patch field roll so that Debian/Apple/Elixir/whatever tooling stays happy. For customer facing stuff, I've moved to calendar versioning (2021.08.12). It's easier and no or more less effective than arbitrary and debatable decisions to encodify some value when major/minor/patch changes.
- dnautics 5y ago
  I would think that ZeroVer is illustrating that Semantic Versioning itself is working exactly as it should by exposing the anxieties that OSS developers and communities have.
ohdannyboy 5y ago
The idea itself was not obviously satire to me, sadly. Once I saw the list I realized they were making fun of using version 0 as an excuse for unfixed bugs.
chaboud 5y ago
This is actually a great little advertisement for CalVer and SemVer baked into a send up of some pretty important projects with goofy ZeroVer history. I use ZeroVer on documents that are in a draft state to signal that they're draft, and the version drops once the doc is final. SemVer is great for protocols, as it signals compatibility promises, and the ZeroVer alias of a protocol version means it's in development (there be dragons). CalVer is great for software releases, operating systems, etc, as it makes debugging/triaging easier. Whichever you use, version your protocols and releases please. It's an incredibly common problem with software, that people don't think about the value of versioning and the impact it has on parallelism in engineering/development. Versioning. Do it.
kazinator 5y ago
They forgot Linux, which started at 0.x and was at 0.99plX for a number of patch levels X before being released as version 1. The minor numbers should always start at zero. The major number starting at zero lets us express that the program is not released. I.e. we are actually using 1-based versioning for the major number, and are reserving the 1 for the first stable release when the beta program is considered to have shipped.
g5095 5y ago
Why don't we just start off with OnehundredVer, to make the point that version numbers are arbitrary silliness and nothing whatsoever to do with marketing?
PebblesRox 5y ago
ZeroVer is versioning for perfectionists. https://news.ycombinator.com/item?id=28089287 https://news.ycombinator.com/item?id=28089287
- astrobe_ 5y ago
  In some sense yes. It can mean that the authors think that they are not done with it. In some cases, the cause can be a insufficiently defined scope, and feature creep can be a consequence. In other cases, authors might have the correct intuition that the first impression can be very important, so going out and releasing Version One can cause great anxiety.
krinchan 5y ago
I realize terraform turned 1.0 recently but I still harbor a lot of anger towards them for 0.11 to 1.0. They were selling support and enterprise features and convinced everyone to go all on on terraform and the result was pure hell getting from minor version to minor version. Upgrade fatigue set in hard in my org and I still have teams I stumble across sitting on 0.9 and refusing to upgrade. The only pass terraform gets is that it was the least worst of IaC at the time. And even now in the day of k8s, on-cluster CI/CD, and AWS-account-per-team, something has to provide the initial k8s cluster, VPC, Client VPN, etc. before your devs can use an account.
- busterarm 5y ago
  Uhh...I've been using Terraform at very large scale since 0.7, without Enterprise, and the only truly painful upgrade in this chain was 0.11 to 0.12. There might have been some pain in specific providers, but at the same time those updates were going on, all three major cloud providers rewrote their own APIs. Everything since 0.12 has been literal sunshine and rainbows flying out of our butts. The tool is _that good_ now.
  - krinchan 5y ago
    We have an internal provider that handles generation of IAM Roles and IAM users via an external API for various security reasons I may or may not agree with. The constant provider changes in 0.10 and upward were extremely painful. We actually ended up having several teams who so hopelessly fubared their tfstates trying to skip minor releases, we ended up having to take it away and put together a task force to do it ourselves across almost 200 repositories. I’m not sure what you mean by “all three major cloud providers rewrote their own APIs.” Azure[1][2], AWS[3], and Google[4] are all maintained by Hashicorp. In fact, if you peruse the issues you’ll often see PRs opened by employees of the respective providers trying to fix blocking issues and they often devolve into literal begging for Hashicorp to respond and at least tell them why something hasn’t been merged. I know one blocker[5] actually cost Azure a very substantial customer as it languished in Hashicorp’s queue. Hashicorp’s constant refrain of “Well it’s a 0 version software” while selling enterprise support and constantly shilling their wares as production ready across the entire DevOps space was dishonest. I appreciate the position they were in and I appreciate even more their attempt to at least put out a good PR move with their 1.0 release. We will see how well it holds up over the years. What you call “that good” I call “better than everything else but still byzantine and hellish to deal with every time someone DMs me, ‘hey, you know terraform right?’” 1: https://github.com/hashicorp/terraform-provider-azuread https://github.com/hashicorp/terraform-provider-azuread 2: https://github.com/hashicorp/terraform-provider-azurerm https://github.com/hashicorp/terraform-provider-azurerm 3: https://github.com/hashicorp/terraform-provider-aws https://github.com/hashicorp/terraform-provider-aws 4: https://github.com/hashicorp/terraform-provider-google https://github.com/hashicorp/terraform-provider-google 5: https://github.com/hashicorp/terraform-provider-azurerm/pull/5485#issuecomment-591608953 https://github.com/hashicorp/terraform-provider-azurerm/pull...
njharman 5y ago
I can't tell if this is a spoof or joke? This entire section reads like a joke post > 0verview Unlike other versioning schemes like Semantic Versioning and Calendar Versioning, ZeroVer (AKA 0ver) is simple: Your software's major version should never exceed the first and most important number in computing: zero. A down-to-earth demo: YES: 0.0.1, 0.1.0dev, 0.4.0, 0.4.1, 0.9.8n, 0.999999999, 0.0 NO: 1.0, 1.0.0-rc1, 18.0, 2018.04.01 In short, software versioning best practice is like the modern list/array: 0-based. We'll leave it to computer scientists to determine how expert coders wield the power of the "zero-point" to produce top-notch software. Meanwhile, open-source and industry developers agree: ZeroVer is software's most popular versioning scheme for good reason.
mrtweetyhack 5y ago
So if there is always a 0. in front, then just take it out an assume it's there
KingMachiavelli 5y ago
It's satire but technically some of those projects may just be following SymVer [1] but have never reached the point of being able to claim whether an update is breaking or non-breaking. [1] https://semver.org/ https://semver.org/
astrobe_ 5y ago
How could they miss 0 A.D.!
lvxferre 5y ago
Guys. I'm not even a programmer, but even I could notice right off the bat this is satirical, when they claimed there's some "consensus" about major versions being over. That said I wish developers realised more often, how meaningful version numbers are for the users. Zero as a major version screams from a distance: "we're just testing stuff out, expect features to be added and promptly removed because they shouldn't be there, this is not production-ready, use it at your own risk".
deleted 5y ago
[deleted]
maxekman 5y ago
For backends etc I like to use year.week.build: v2021.32.1 for today’s build.
andrewmcwatters 5y ago
Instead of listening to authors, I evaluate for large projects what the actual semantic version of a piece of software is, and other people should do the same. If someone says they're 0.11.4 and they broke the API 115 times in major, non-compatible ways over the last decade, they're 115.x.x, period. To assume otherwise is just admiring window dressing.
bacan 5y ago
Not sure if this a joke, but zerover sounds like the worst idea ever. Whole numbers are intuitive, easy to understand and easy to compare. It is way easier to compare something like 1.0 & 2.0 than it is to compare 0.1.9 & 0.2.0-rc.2 Plus then you get the added advantage of Major/minor versions.
kazinator 5y ago
CVS/RCS is "guilty" of 1-based versioning. The linear version history of a RCS file goes 1.1, 1.2, 1.3. If we shoot a branch off, say, 1.2, that becomes 1.2.1.1, 1.2.1.2, 1.2.1.3, ... Switching that dead horse to zero-based would have been a solution in search of a problem even in its heyday when it was considered viable. (BSD people, feel free to read that as "today"). We don't do arithmetic on version numbers, or not any that involves higher power operations like multiplication so the origin of the numbering doesn't matter. The components of versions are not always numeric anyway. Is 1.3.A zero-based or not? Is A the zero of the alphabet or the one? Versions for creative works have been traditionally one based. The first edition of a book is edition 1. The only good thing about zero is for indicating an alpha or beta version not considered to be released/published.
kzrdude 5y ago
major useful software like numpy and pandas were using 0.x versions for a long time. They were useful for all that time, and books were written, but they have now both come over to 1.x versions (pandas more recently than numpy).
cookiengineer 5y ago
I know this is a joke, but... Honestly, nobody gives a damn about software version numbers outside the developer world. Do you think your endusers care about semantic or zero versioning? Probably not. I liked the Ubuntu (or previously msoffice) approach, as people can predict when new software is going to be released, and they immediately know how old an installation is. Maybe someone should propose a year / datetime based versioning scheme here...
jessaustin 5y ago
TFA: ...software versioning best practice is like the modern list/array: 0-based. elsewhere in TFA: Welcome to ZeroVer 0.0.1. Anyone familiar with zero-based lists surely would have suggested "0.0.0"?
- seaish 5y ago
  I'd like to think 0.0.0 is when the idea is still in your head.
divbzero 5y ago
SemVer FAQ [1] specifically recommends starting with 0.1.0. [1]: https://semver.org/#faq https://semver.org/#faq
dbrueck 5y ago
IMO the best versioning convention is YYYYMMDDNN, where NN is the release number you did that day (and so is typically 0). With this, it's trivial to generate new version numbers, there's no version number angst, and version numbers are inherently ordered. Detractors will argue that this system doesn't convey compatibility or magnitude-of-change information, but that's a feature.
NetOpWibby 5y ago
This seems ironically complex. If starting from zero, why have any dots at all? Don’t make sense. I’ll continue using ChronVer. https://chronver.org https://chronver.org (Full disclosure, this is my site)
hzhou321 5y ago
On the other hand, I am also quite annoyed that some projects do yearly major version after 1.0.
lamontcg 5y ago
What this really does is highlight the way that SemVer is broken. Or at least the arguments that users and maintainers have over SemVer is broken.
pabs3 5y ago
My favourite version system is PiVer, where you start with version 3.1 and then progressively add more digits from Pi. IIRC one of Joey Hess' projects did this.
mybrid 5y ago
Versioning is marketing. This is just the latest Coke Zero. Anything public facing is marketing. I remember when marketing got ahold of memory and disk size in the 1980s Then it was CPU size. Size matters. As someone once quipped, "If winning dosen't matter then why do they keep score?" Micrsoft can't release annually and Apple iOS can. That's a score. Marketing is about selling the sizzle and not the steak and versions sizzle. Forget trying to make public meaning out of them. Sales can sell bigger is better.

570 points by polm23 5y ago

This is being sold as "Cutting-edge software versioning for minimalist" but requires you to have an additional number in your version that does nothing

quickthrower2 5y ago
It’s like saying the UTF BOM does nothing. The 0. prefix tells you it’s an enlightened project.

deleted 5y ago

[deleted]

Errik 5y ago

I've to admit it: I read through it with increasing disbelief, feeling old and outdated, until I've reached the release date.

StephenJGL 5y ago

I love the religious overtones on the post. All I can say is that the best option is probably to coexist.

robertlagrant 5y ago

Here's something that's not zero: the number of comments from people that don't get the joke.

rojoroboto 5y ago
this is my favorite comment.
tonyedgecombe 5y ago
Humour is wasted on Hacker News.

kasperni 5y ago

ZeroVer is satire [1]. [1] https://0ver.org/about.html https://0ver.org/about.html

ycuser2 5y ago
Thank you... I couldn't understand the reason to use it.
- mjburgess 5y ago
  It's so you can tell your users that the bugs aren't going to be fixed yet. It'll be ready by v1.
  - joshxyz 5y ago
    and you can break the api anytime
  - jeltz 5y ago
    I would say that it is more about avoiding to promise anything about API stability between versions.
inanutshellus 5y ago
...and so it's explicit... the homepage's table of projects is a Wall of Shame.

toabi 5y ago

But hey… even terraform made it to v1.0.0 after some time… https://github.com/hashicorp/terraform/releases/tag/v1.0.0 https://github.com/hashicorp/terraform/releases/tag/v1.0.0

andsens 5y ago
... and they geared up for it by releasing two breaking versions in the year leading up to v1.0.0. I managed to catch the entire upgrade path from 0.11 to 0.12 to 0.13 to 0.15. Good times.
- bavell 5y ago
  It was so fun reinstalling old terraform versions so I could unfuck my cluster infra... not to mention the joy of finding they removed the .13->.14 migration command in .14 so you have to roll alllll the way back... Good times indeed.

eurasiantiger 5y ago

Shenanigans aside, 0.x versioning is commonly used when developers cannot (yet) make any guarantees about backwards compatibility between minor releases.

dilap 5y ago
At the risk of sucking the fun out of a pretty funny joke, I think the underlying subtext is that established projects are failing to "grow up" -- i.e., that established, depended-on projects are hiding under the shield shield of a youthful 0.x version, when really, given how popular, old, and depended-on they are, they should embrace that responsibility and grow into 1.something. (Though, on the other hand, maybe it's more just honest signaling of expectations. "We are a 0.x project, we value developer speed and a clean code-base more than backcompat or stability for users. We will NEVER grow up!" We could call it Peter Pan versioning.)
- eurasiantiger 5y ago
  I’d hazard a guess that many of those projects are for environments that cannot guarantee stability, so the instability kind of rolls over to the projects themselves.
- robertlagrant 5y ago
  I think they just don't care about marketing. 1.0 being grown up is a marketing perspective. You could start at 2.0 and not be "grown up" in the slightest.
  - inanutshellus 5y ago
    This is an unhelpful argument. It effectively says "meaning doesn't exist". I could also version my software "chicken.banana.guacamole" and be pissed that nobody understood that meant it was enterprise-and-production-ready. Point is, there's a convention and this satire website is pointing out obviously-wrong cases of mis-versioning.
    - 5y ago

necovek 5y ago

I did not find it a very compelling joke until I checked out the list of projects: some running their "0.*" versions for 10+ years, and many a familiar name in there too — ouch! That made me laugh out hard :D

soraminazuki 5y ago

Neovim is listed as a "notable ZeroVer project" and yet it has a 1.0(!!) milestone in the GitHub project page. https://github.com/neovim/neovim/milestones https://github.com/neovim/neovim/milestones

colonwqbang 5y ago
> 0% complete > No due date > Last updated over two years ago Looks like a classic case of ZeroVer!
- quickthrower2 5y ago
  Replace “case” with “practitioner” please. It’s not a disease!
  - jrochkind1 5y ago
    Are you sure about that?

mjburgess 5y ago

Seemed like a strange joke until you see the table, Project Stars Released Releases Current Version 0ver years React Native 96,747 2015 359 0.65.0-rc.2 (2021) 6.3 ...lol God forbid tor, sklearn, react-native release a v1 -- people might expect things!

k__ 5y ago
Many OSS projects were and still are pre 1.0 for years. I think, it's a sign of hybris if a project owner goes 1.0 too soon.
- julianlam 5y ago
  ... hubris? I think that's a bit much. We went v1 once we decided our software was ready for other people to use. It meant we'd ensure compatibility via upgrade scripts, and it meant we wouldn't do irresponsible things like tell users "this release requires you to drop your database and start over"
  - k__ 5y ago
    I think, that's the main problem with SemVer. Everyone tries to merge the major version with some kind of nebulous "readiness". While it should just be a number related to technical aspects of the software.
  - superjan 5y ago
    And I think that is the right way to think about it. I think people stay on 0 because they think they have to implement all ideas and edgecases before it you can call it 1.0. You can also get stuck on 1.x releases in the same way (notably Java).
- mytailorisrich 5y ago
  If you have a set of working, useful features, however small as long as they part of your core product, and you release to the public then you have your v1.0. IMHO, if you stay pre 1.0 for years across many releases it means you have too wide a scope for what v1.0 should be. Essentially, your MVP is v1.0 since that the first viable product you release. But what sometimes happens is that people imagine v1.0 as being the full vision with everything and so they never really reach it. And of course sometimes it seems that there is no sensible explanation at all for why a product is still pre 1.0 to the point of being ripe for satire, indeed (and ZeroVer is really on point the way it satirises this!).

jokoon 5y ago

using the an ISO date with a release/beta/branch-name as a version number always make more sense to me...

eurasiantiger 5y ago
Proper semantic versioning gives you certain guarantees. Consider you’re on v1.2.1 of some package, pinned to your requirements as ”^1.2.1”. A security issue gets fixed, v1.2.2 is released, your CI/CD can manage this upgrade automatically. A new feature is introduced, v1.3.0 is released, your CI/CD can still manage this upgrade automatically. Developers know that there are new features because the minor version was incremented. But then, some core API refactoring is done to support new integrations, which happens to break backwards compatibility. Now, v2.0.0 is released, and it is obvious to developers that something major has changed. Your CI/CD does not do this upgrade automatically.
- kashug 5y ago
  we tried semantic versioning for some time, but gave up. It is still people writing the code - and people do mistakes. So even when something is released as a patch how do we know that it was a mistake and it should have been a minor or a major version. Or they introduced a bug that would break our system? So in the end we would still end up not trusting it and rely on testing (hopefully as automatic as possible) before we could merge the upgrade. In the end we just switched to using timestamp-based version numbers and just try to upgrade often enough so each incremental change is small. And try to have good automatic tests that can do most of the regression testing for us.
  - jeltz 5y ago
    Miatakes happen but as an end user of a library I prefer having semantic versioning giving me a hint on where it is likely there is an API breakage and where there is unlikely to be one. I still use lock files, read release notes and test but knowing where things are likely to break saves me time.

dmos62 5y ago

> Low in the stack, low in the version. That's the HashiCorp way. > Most experts have come to agree, for all their complexity and absurdity, Kafka's writings have been influential, despite the prevalence of bugs. I'm loving this.

khanan 5y ago
Too bad the "article" is written in 2018 and Hashicorp release Vault 1.0.0 December 3rd, 2018 :)
- Sebb767 5y ago
  It seems HashiCorp got the message ;)
- nonameiguess 5y ago
  It actually has Vault, Terraform, and Nomad in the Projects Emeriti section at the bottom. They just never edited the original article. It appears Inkscape was the longest holdout, and went 19.7 years before finally releasing 1.0, though that's only of projects that did make the cutover. Some chemical process modeling software out of CMU called "Ascend" has been proudly avoiding 1.0 since 1978. I'm not sure how to get it as their website no longer seems to work, but apparently they were part of Google Summer of Code five times.
smsm42 5y ago
Kafka part is brilliant, too bad they went to the dark side with 1.0 release in 2017.

gHosts 5y ago

I wish I was joking. But our versioning scheme doesn't include zero. Not even for minor version numbers. As we (rightly) believe our customers don't trust them (for good reasons).

ThePadawan 5y ago
All humans are weird. If you're not used to reading version numbers, you'd be surprised that 1.10 comes after 1.9 and vice versa.
- blueflow 5y ago
  Only in the US, the rest of the world also uses this format for dates: 1.10 is 1st october and 1.9 is first september.
  - Joker_vD 5y ago
    Even in the US format, the 10th of January is still after the 9th of January. Perhaps the correct sentiment would be "If you're not used to reading, you'd be surprised that 1.10 comes after 1.9 and vice versa".
    - ThePadawan 5y ago
      I have no idea how you or your parent immediately arrived at calendar dates (which in my book require a period at the end), but to everyone i know, 1.10 is not a date, but a floating point number with the same magnitude as 1.1, which is thus closer to 0 than 1.9 is.
      - blueflow 5y ago
        How would October 1st be written down at your place?
        ThePadawan 5y ago

styren 5y ago

Obviously they've gotten a lot of inspiration from my favorite: Sentimental Versioning http://sentimentalversioning.org http://sentimentalversioning.org

jabiko 5y ago

Helmfile might be a good addition to the list: https://github.com/roboll/helmfile/releases/ https://github.com/roboll/helmfile/releases/

quickthrower2 5y ago

The best versioning is the one you already have and use every day. It is right under your nose. You probably typed or pasted one or these special version strings in today or you will later. Or you sent one to a colleague in a slack message this week most certainly. It is of course the git commit hash! Suck all meaning out of your version by using the commit hash. Never worry about which digit to increment (semver, 0ver) or what date it is (calver) because who remembers the date. Also has the advantage that it’s easy to check out the source code for a version! Use git log and pipe that to a file in /var/www and you have release notes with the version numbers!

BiteCode_dev 5y ago
Really handy to communicate verbaly or promote.
- wraptile 5y ago
  You just keep appending spaces until commit hash sounds human! Check out latest release: h0rs35l0v3b4tt3ry4cid5! Eventually people will start random commits like "random commit to change hash" when commits accidently result in racist or taboo terms lol
ricardobeat 5y ago
And have no idea how recent the version is unless you have immediate access to git. It’s a very engineer-centric idea.
choeger 5y ago
If that's not sarcasm, and I am really not sure whether it is, just one counter argument: commit hashs are not ordered and they can change.
- account42 5y ago
  > they can change This is incorrect. You can create a new commit with a different hash, but the commit hash being a checksum of the commit contents will never change for the same commit.

reckoner22 5y ago

An alternative would be to introduce a „marketing version „number independent of the semver version. Usually there are packages with big api differences for the first 3 versions or so. The major version number is used to discuss bugs, development, etc. New versions usually entail a beta period that results in two active versions for a while. This would allow the major version to be used more often for breaking changes to help with automated dependency update tools.

jeltz 5y ago
PoatgreSQL used to do this and they abandoned it for good reasons. Too much bikesheddinr about when the marketing number should be incremrnted and too many confused users who (with good reason) thought the marketing number actually meant something.

bungle 5y ago

True ancestor to this: https://en.m.wikipedia.org/wiki/Enlightenment_(software) https://en.m.wikipedia.org/wiki/Enlightenment_(software) ” The first version of Enlightenment was released by Rasterman (Carsten Haitzler) in 1997.[5] Version 0.17, also referred to as E17, was in development for 12 years starting in December 2000[6] until 21 December 2012 when it was officially released as stable.”

jiggawatts 5y ago
That brings back some memories! Back in '98 or '99, I ran into Carsten at UNSW and started talking to him because I thought it was cool how he used roller blades to go between classes. He set up my Linux login with Enlightenment before many people had even heard of it. My fellow students in the same year were using some hideous black & white (not even greyscale!) window manager, meanwhile I had this awesome colourful setup that felt like it was from the future. Fun times...

twobitshifter 5y ago

Having worked at a place with 11+ years of a project in ZeroVer, I would caution against ZeroVer as it can mentally wear on software developers. The 0. is not something embraced, but a taunting God who takes pleasure in suffering. The followers of ZeroVer all believe that with some combination of magic and hard work a 0. will turn to a 1., but the mighty 0. never rolls over. To topple the 0., they will try tricks like a full rewrite of core code, new scrum patterns, new directors of software development, more code reviews, iron clad specifications, testing specialists, and more. They’ll try to do things they see 1.0 software doing: sell the code, use it in production, make billion dollar decision based on its output, have entire livelihoods wrapped up in its existence, and still the 0. is unchanged. The myths of a roadmap to 1.0 will build over time, some say it’s always existed, but there’s no sign of a road or even civilization when you look around. The ZeroVer faith says that everyone is always on the road to 1.0 if they believe, but outsiders continually taunt them for not knowing when 1.0 will reveal itself.

arcatek 5y ago
I know you're joking, but I worked in a startup where a massive effort was made to completely rebuild the 1.x website - both backend and frontend. It required a lot of work from everyone, and I remember we even stayed late more than a few times to bring it to finish line. So it was a bit disheartening that the founders never bumped the version to 2.x once the rollout was achieved. It's perhaps a bit nitpicky, but it felt like the work wasn't properly appreciated.
- koheripbal 5y ago
  Maybe I'm aged, but I always just use the date. If I build today, the version will just be 210811.1 and it updates automatically in each build. I'm a one man shop though so I never branch for major/minor releases.
  - tonyhb 5y ago
    This is the exact strategy we use for our rollouts too. 2021-08-12.01 was just released.

makach 5y ago

...wait, this is a joke?! ..right? *edit: yes, published 1 april 2018

lloydatkinson 5y ago

Is this a joke or a real site? How does basically putting a 0. in front of every version solve anything?

keithnz 5y ago
a joke and a not so subtle prod at all these long running projects that are stil 0.something

matsemann 5y ago

I always bump major even though we follow semver. I consider my contributions major no matter how small. No impostor syndrome here, sir. (/s)

lugged 5y ago

I remember when you might worry about getting fired using alpha version code in production.

pbhjpbhj 5y ago

Inkscape is a notable 0ver user until a recent lapse! I'm still on 0.9... , for, y'know, religious reasons. 18 years on a 0ver is hard to quit! (Seriously, I'm not sure the 1.0 is in the Kubuntu repos for my version). https://launchpad.net/inkscape/+milestone/1.0 https://launchpad.net/inkscape/+milestone/1.0

allo37 5y ago

I feel like this is meant to be satire, but I wonder if there's some truth to it: Usually updates to a "major" version come with an implied assumption that there won't be any breaking API changes. Maybe being perpetually at 0 gives you the "It's beta software, you need to update bro" defence against maintaining a stable API, and all the extra overhead that comes with it.

a3w 5y ago
Why not release 2.x after a month, breaking the API again? Heck, why not next day when you find out that all APIs suck.
- allo37 5y ago
  Because you'll still have customers on version 1.x, who will still expect support and refuse to update for <reasons>. It's not that it's impossible but it imposes an additional burden on the development team, which affects how fast you can add features.
  - mahkoh 5y ago
    That's why our team at GigaCorp has switched to not using minor version numbers. In the past we had customers who expected continuous security updates without updates to the minor version due to some internal policy. All of our new products use 0.0.x versioning where x is incremented for each release. This way we can easily push out new releases and our customers have no reason to delay updates.
  - remram 5y ago
    But that's the same with 0.1 and 0.2. You will still have users in 0.1 who will expect support and refuse to update.
    - allo37 5y ago
      Unfortunately irrationally difficult customers are a bit like death and taxes in that sense, but "We have a new version with some minor fixes that you can use" is generally an easier sell than "We have a new version with some major changes that will completely disrupt your workflow".

amarant 5y ago

So why is react native still 0.x? Is it really still unstable after 6 years? Seems like they should settle on a API already...

hnlmorg 5y ago

> To drive the point home, even further down the stack, HashiCorp's Terraform also complies with ZeroVer's cutting-edge versioning scheme. With Vault and Terraform, HashiCorp demonstrates industry recognition of the importance of ZeroVer in infrastructure. Both of these have seen 1.x releases.

inanutshellus 5y ago
Page was made April 1st, 2018, so that's probably just bitrot. That said, I like to think they did 1.x releases specifically because they were hoping to get off this Wall of Shame.

hyperman1 5y ago

WindowMaker! I remember using it at the end of the 90s, thinking: It is fine. Just go to 1.0 already. Yet here we are, 20 years later.

404mm 5y ago

It’s borderline comical to read such strong opinions about how to version your software. “One shall not speak of 1.0!” (Not an actual quote). If 0ver works for your use case, go with it, by all means. It’s sortable (“nat-sortable” to be more precise) and it will get the job done. And so are many other versioning schemes. Think about your release cadency, how will you release new versions, patches and fixes and then pick one that makes sense to both humans and your code.

shawxe 5y ago
I'm pretty sure the page is supposed to be satirical. It's poking fun at the number of software projects that have been around for several years (or maybe even a couple of decades), have had dozens to hundreds of releases, and yet are somehow still at major version 0, which flies in the face of both semantic versioning and general common sense.
- 404mm 5y ago
  Wow, lol. I usually pick up on satire. It’s just …it’s 2020-ish and it looked very aligned with various edgy opinions.

jrochkind1 5y ago

This is sarcastic/satire, pretty sure? Not sure all the comments are catching that. When I have to use a 0.x-versioned package because it's a (hard or soft) dependency of some popular framework/platform/tool that "everyone" is using... I feel personally insulted. Like they're saying "no, we're not willing to say this is production-ready, we're not willing to say that we're not going to break backwards compatibility every month or so in a way you can't predict from the version number so can't do automated dependency updates ever, but, hey, everyone else is using it, what's your problem?" It's like the ultimate embrace of the typical HN "open source maintainers owe you nothing and you should expect nothing of them" argument. Which is true, but if all packages literally made no effort to meet user needs and we had learned to expect nothing from them, we would never be using open source....

vitro 5y ago
From the About page: > ZeroVer is satire, please do not use it.
- smsm42 5y ago
  Unfortunately, from the main page it's clear everybody does anyway.
JadeNB 5y ago
> When I have to use a 0.x-versioned package because it's a (hard or soft) dependency of some popular framework/platform/tool that "everyone" is using... I feel personally insulted. Like they're saying "no, we're not willing to say this is production-ready, we're not willing to say that we're not going to break backwards compatibility every month or so in a way you can't predict from the version number so can't do automated dependency updates ever, but, hey, everyone else is using it, what's your problem?" Wait, insulted by whom? The package developers are surely not obliged to develop their package to a standard that satisfies you, and it's hardly their fault if someone else feels that their package is useful enough to integrate it into something popular. Insulted by the popular framework that uses it … maybe, but you are not willing to forgo the use of 0.x-versioned packages even when it is a point of principle for you, so why should the developers of those frameworks forgo it when it is not a point of principle for them?

altcognito 5y ago

ElasticSearch was pretty solid when it was under zerover

deleted 5y ago

[deleted]

WaitWaitWha 5y ago

0. versioning sits on the throne of lies. The major and minor versioning continues within 0ver, just prepended with 0. As @twobitshifter (facetiously?) & @arcatek wrote, it messes negatively with the minds of developers. And, for decades we have been training non-technologists 0. is not production, 1. is better than 0., and 2. is better than 1.

everyone 5y ago

Oh its a joke? Poe's law was in effect for me.

jl6 5y ago

It’s a joke at the expense of projects whose developers have no idea when their own software will be finished. You can’t ever get to version 1 if you have no clear goal or sense of what being done means. The idea of requirements is now thoroughly out of fashion. And I suspect that a lot of projects stay hazy on their purpose in order to keep the door open for a pivot to the latest trendy concept, or an acquihire.

dhagz 5y ago
I'm going to be pedantic and say the idea of fixed requirements is out of fashion. The software I write has requirements, but they change about 1/3 of the way through each sprint.

ziml77 5y ago

I hate that so many projects don't ever move to version 1. It makes it hard to choose to use them for anything serious because 0.x implies that the developers don't think the project is ready yet. I think the reason projects get stuck at 0.x is because of interface stability expectations. When you're at version 0, you have the freedom to realize you made a bad choice and break interfaces to improve it in the long run. It's nice to know you have that freedom and that you're not committing to maintaining something in a state that is painful to work with.

another-dave 5y ago
Semver also allows you to make breaking changes at anytime with the bump from one major version to the next — e.g. if you look at something like RxJava they use semver well in this way & don't shy away from breaking changes to deprecate and tidy the API. If anything I think perpetual v0 dilutes the concept as gets people used to projects being stable at v0 rather than considering them alpha

smcameron 5y ago

Heh, my hobby project has been at version 0.1 since 2012 I think. But it's ok, because I've made no releases (it only runs on linux, and you have to compile it yourself. I find this keeps the quality of users, bug reports, complaints, etc. higher and the numbers lower). And also, it's a silly space game, so nobody cares anyway. And the really important thing to version is the network protocol it uses, currently at 53. The "versions" of the software are really the git commits. I try really hard to ensure every commit is viable (so that git bisect works, and so the top of the tree always works).

ziggus 5y ago

My versioning scheme is based on UNIX timestamps of releases, all concatenated together. Something like this: {major release timestamp}.{minor release timestamp}.{last patch timestamp}, which winds up like: 1542051468.1576431468.1613410668 Very clear and easy for users to understand.

lmilcin 5y ago

I believe that after half a dozen releases 0 stops being meaningful and is just reflection on somebody's inability to make a decision. I make my point by always numbering my first prod release as 1.0.0. It is never going to be perfect and it is always going to be in state of flux. Why try to push responsibility onto client by telling them "Guys, we have warned you, this is still version 0"?

Agentlien 5y ago

I enjoyed this. It was funny and had some really good jabs at some of these projects. I'm also happy that its list of notable ZeroVer projects includes Dwarf Fortress, currently at v0.47.05, 15 years after the first version was released.

MauranKilom 5y ago

Looks like fail2ban (16.8 years of being zero-versioned according to this site) is actually on the path to a 1.0 release: https://github.com/fail2ban/fail2ban/commit/3f5c382a988bb21f48a0fe3a26c2433d04f7076f https://github.com/fail2ban/fail2ban/commit/3f5c382a988bb21f... Well, the master branch is considered 1.0 at least. Not sure if there's been an official 1.0 release though...

dathinab 5y ago

The fear of not releasing 1.0 because of some strange believes that you can't release 2.0, 3.0 or 2364.0 or that 1.0 needs to be special in some way is really annoying. The moment your software is production ready it should not take long until you use major version numbers. If you are afraid of users expecting no change breaking after 1.0 don't stay below it as the user also expects 1.0. instead brake expectations by avoiding 1.0 and 2.0 specifically. E.g. jump from 0.69.0 to 69.0.0 or some other arbitrary number like 42.0.

exabrial 5y ago

If it really bothers you, I could write a script that subtracts 1 from semver compatible version numbers on checkout, and increments on push.

keiferkif 5y ago

I was ready to lose it on what I perceived as more pretentious developer shit, then I realized it was satire thank the Ford.

devy 5y ago

This blog post titled "ZeroVer: 0-based Versioning" was originally written on April 1, 2018, even though the "Notable ZeroVer Projects" section seems to be updated and current for this year. The canonical URL is https://0ver.org/zerover_0_based_versioning.html https://0ver.org/zerover_0_based_versioning.html The entire site only has a single blog post. Go figure.

snicker7 5y ago

A brutal admission that modern software is broken and that stability, predictability, and correctness is just too much to ask for.

david927 5y ago

I know it's all in jest but this bothered me: > Franz Kafka, who lived as an author in turn-of-the-20th-century Austria Kafka lived his whole life in Prague, Czech Republic. Yes, it was at the time within the borders of the Austrian-Hungarian Empire, but calling him Austrian is irksome.

wott 5y ago
> Kafka lived his whole life in Prague, Czech Republic. Kafka had been dead for 70 years when Czech Republic came to existence. He even lived only a handful of years in Czechoslovakia since he died young. So saying he lived most of his life in Austria is more correct, than assigning him to an entity which didn't exist at all at the time.
- david927 5y ago
  Nope. You can say Austrian Hungarian Empire or better, Prague. He, and the people of the time, would not say they lived in Austria -- which didn't exist either. The people of the area spoke Czech. You can't shorten the Austrian Hungarian Empire to Austria or Hungary. It's both lazy and wrong. Also, the Czechs fought hard for their independence and achieved it during Kafka's lifetime. In the same way, literally no one says, "George Washington, Ben Franklin and Thomas Jefferson, who lived in 18th-century England..." We don't call them English, despite having been born in a colony of England, because they identified themselves as American and were officially recognized as that in their lifetime.
- kzrdude 5y ago
  Compare to someone like George Washington. He grew up in the british empire, in their territory. That's the fact, yet it sounds wrong to call him british.

mbfg 5y ago

Our teams fully embrace ZeroVer versioning. Since we all agree ZeroVer versioning is superior, we have dropped the leading zero from our version numbers and know that is just implied to be there. We are all happy and rejoice!

travisgriggs 5y ago

ZeroVer is obviously satire, but doesn't it just demonstrate that "Semantic Versioning" works great as a theory, but struggles to keep up with the nuances of the real world? I have multiple sub components of our system that are effectively ZeroVer, not because I love zero ver at all, but because basically a simple linear integer would have worked, so I just let the patch field roll so that Debian/Apple/Elixir/whatever tooling stays happy. For customer facing stuff, I've moved to calendar versioning (2021.08.12). It's easier and no or more less effective than arbitrary and debatable decisions to encodify some value when major/minor/patch changes.

dnautics 5y ago
I would think that ZeroVer is illustrating that Semantic Versioning itself is working exactly as it should by exposing the anxieties that OSS developers and communities have.

ohdannyboy 5y ago

The idea itself was not obviously satire to me, sadly. Once I saw the list I realized they were making fun of using version 0 as an excuse for unfixed bugs.

chaboud 5y ago

This is actually a great little advertisement for CalVer and SemVer baked into a send up of some pretty important projects with goofy ZeroVer history. I use ZeroVer on documents that are in a draft state to signal that they're draft, and the version drops once the doc is final. SemVer is great for protocols, as it signals compatibility promises, and the ZeroVer alias of a protocol version means it's in development (there be dragons). CalVer is great for software releases, operating systems, etc, as it makes debugging/triaging easier. Whichever you use, version your protocols and releases please. It's an incredibly common problem with software, that people don't think about the value of versioning and the impact it has on parallelism in engineering/development. Versioning. Do it.

kazinator 5y ago

They forgot Linux, which started at 0.x and was at 0.99plX for a number of patch levels X before being released as version 1. The minor numbers should always start at zero. The major number starting at zero lets us express that the program is not released. I.e. we are actually using 1-based versioning for the major number, and are reserving the 1 for the first stable release when the beta program is considered to have shipped.

g5095 5y ago

Why don't we just start off with OnehundredVer, to make the point that version numbers are arbitrary silliness and nothing whatsoever to do with marketing?

PebblesRox 5y ago

ZeroVer is versioning for perfectionists. https://news.ycombinator.com/item?id=28089287 https://news.ycombinator.com/item?id=28089287

astrobe_ 5y ago
In some sense yes. It can mean that the authors think that they are not done with it. In some cases, the cause can be a insufficiently defined scope, and feature creep can be a consequence. In other cases, authors might have the correct intuition that the first impression can be very important, so going out and releasing Version One can cause great anxiety.

krinchan 5y ago

I realize terraform turned 1.0 recently but I still harbor a lot of anger towards them for 0.11 to 1.0. They were selling support and enterprise features and convinced everyone to go all on on terraform and the result was pure hell getting from minor version to minor version. Upgrade fatigue set in hard in my org and I still have teams I stumble across sitting on 0.9 and refusing to upgrade. The only pass terraform gets is that it was the least worst of IaC at the time. And even now in the day of k8s, on-cluster CI/CD, and AWS-account-per-team, something has to provide the initial k8s cluster, VPC, Client VPN, etc. before your devs can use an account.

busterarm 5y ago
Uhh...I've been using Terraform at very large scale since 0.7, without Enterprise, and the only truly painful upgrade in this chain was 0.11 to 0.12. There might have been some pain in specific providers, but at the same time those updates were going on, all three major cloud providers rewrote their own APIs. Everything since 0.12 has been literal sunshine and rainbows flying out of our butts. The tool is _that good_ now.
- krinchan 5y ago
  We have an internal provider that handles generation of IAM Roles and IAM users via an external API for various security reasons I may or may not agree with. The constant provider changes in 0.10 and upward were extremely painful. We actually ended up having several teams who so hopelessly fubared their tfstates trying to skip minor releases, we ended up having to take it away and put together a task force to do it ourselves across almost 200 repositories. I’m not sure what you mean by “all three major cloud providers rewrote their own APIs.” Azure[1][2], AWS[3], and Google[4] are all maintained by Hashicorp. In fact, if you peruse the issues you’ll often see PRs opened by employees of the respective providers trying to fix blocking issues and they often devolve into literal begging for Hashicorp to respond and at least tell them why something hasn’t been merged. I know one blocker[5] actually cost Azure a very substantial customer as it languished in Hashicorp’s queue. Hashicorp’s constant refrain of “Well it’s a 0 version software” while selling enterprise support and constantly shilling their wares as production ready across the entire DevOps space was dishonest. I appreciate the position they were in and I appreciate even more their attempt to at least put out a good PR move with their 1.0 release. We will see how well it holds up over the years. What you call “that good” I call “better than everything else but still byzantine and hellish to deal with every time someone DMs me, ‘hey, you know terraform right?’” 1: https://github.com/hashicorp/terraform-provider-azuread https://github.com/hashicorp/terraform-provider-azuread 2: https://github.com/hashicorp/terraform-provider-azurerm https://github.com/hashicorp/terraform-provider-azurerm 3: https://github.com/hashicorp/terraform-provider-aws https://github.com/hashicorp/terraform-provider-aws 4: https://github.com/hashicorp/terraform-provider-google https://github.com/hashicorp/terraform-provider-google 5: https://github.com/hashicorp/terraform-provider-azurerm/pull/5485#issuecomment-591608953 https://github.com/hashicorp/terraform-provider-azurerm/pull...

njharman 5y ago

I can't tell if this is a spoof or joke? This entire section reads like a joke post > 0verview Unlike other versioning schemes like Semantic Versioning and Calendar Versioning, ZeroVer (AKA 0ver) is simple: Your software's major version should never exceed the first and most important number in computing: zero. A down-to-earth demo: YES: 0.0.1, 0.1.0dev, 0.4.0, 0.4.1, 0.9.8n, 0.999999999, 0.0 NO: 1.0, 1.0.0-rc1, 18.0, 2018.04.01 In short, software versioning best practice is like the modern list/array: 0-based. We'll leave it to computer scientists to determine how expert coders wield the power of the "zero-point" to produce top-notch software. Meanwhile, open-source and industry developers agree: ZeroVer is software's most popular versioning scheme for good reason.

mrtweetyhack 5y ago

So if there is always a 0. in front, then just take it out an assume it's there

KingMachiavelli 5y ago

It's satire but technically some of those projects may just be following SymVer [1] but have never reached the point of being able to claim whether an update is breaking or non-breaking. [1] https://semver.org/ https://semver.org/

astrobe_ 5y ago

How could they miss 0 A.D.!

lvxferre 5y ago

Guys. I'm not even a programmer, but even I could notice right off the bat this is satirical, when they claimed there's some "consensus" about major versions being over. That said I wish developers realised more often, how meaningful version numbers are for the users. Zero as a major version screams from a distance: "we're just testing stuff out, expect features to be added and promptly removed because they shouldn't be there, this is not production-ready, use it at your own risk".

deleted 5y ago

[deleted]

maxekman 5y ago

For backends etc I like to use year.week.build: v2021.32.1 for today’s build.

andrewmcwatters 5y ago

Instead of listening to authors, I evaluate for large projects what the actual semantic version of a piece of software is, and other people should do the same. If someone says they're 0.11.4 and they broke the API 115 times in major, non-compatible ways over the last decade, they're 115.x.x, period. To assume otherwise is just admiring window dressing.

bacan 5y ago

Not sure if this a joke, but zerover sounds like the worst idea ever. Whole numbers are intuitive, easy to understand and easy to compare. It is way easier to compare something like 1.0 & 2.0 than it is to compare 0.1.9 & 0.2.0-rc.2 Plus then you get the added advantage of Major/minor versions.

kazinator 5y ago

CVS/RCS is "guilty" of 1-based versioning. The linear version history of a RCS file goes 1.1, 1.2, 1.3. If we shoot a branch off, say, 1.2, that becomes 1.2.1.1, 1.2.1.2, 1.2.1.3, ... Switching that dead horse to zero-based would have been a solution in search of a problem even in its heyday when it was considered viable. (BSD people, feel free to read that as "today"). We don't do arithmetic on version numbers, or not any that involves higher power operations like multiplication so the origin of the numbering doesn't matter. The components of versions are not always numeric anyway. Is 1.3.A zero-based or not? Is A the zero of the alphabet or the one? Versions for creative works have been traditionally one based. The first edition of a book is edition 1. The only good thing about zero is for indicating an alpha or beta version not considered to be released/published.

kzrdude 5y ago

major useful software like numpy and pandas were using 0.x versions for a long time. They were useful for all that time, and books were written, but they have now both come over to 1.x versions (pandas more recently than numpy).

cookiengineer 5y ago

I know this is a joke, but... Honestly, nobody gives a damn about software version numbers outside the developer world. Do you think your endusers care about semantic or zero versioning? Probably not. I liked the Ubuntu (or previously msoffice) approach, as people can predict when new software is going to be released, and they immediately know how old an installation is. Maybe someone should propose a year / datetime based versioning scheme here...

jessaustin 5y ago

TFA: ...software versioning best practice is like the modern list/array: 0-based. elsewhere in TFA: Welcome to ZeroVer 0.0.1. Anyone familiar with zero-based lists surely would have suggested "0.0.0"?

seaish 5y ago
I'd like to think 0.0.0 is when the idea is still in your head.

divbzero 5y ago

SemVer FAQ [1] specifically recommends starting with 0.1.0. [1]: https://semver.org/#faq https://semver.org/#faq

dbrueck 5y ago

IMO the best versioning convention is YYYYMMDDNN, where NN is the release number you did that day (and so is typically 0). With this, it's trivial to generate new version numbers, there's no version number angst, and version numbers are inherently ordered. Detractors will argue that this system doesn't convey compatibility or magnitude-of-change information, but that's a feature.

NetOpWibby 5y ago

This seems ironically complex. If starting from zero, why have any dots at all? Don’t make sense. I’ll continue using ChronVer. https://chronver.org https://chronver.org (Full disclosure, this is my site)

hzhou321 5y ago

On the other hand, I am also quite annoyed that some projects do yearly major version after 1.0.

lamontcg 5y ago

What this really does is highlight the way that SemVer is broken. Or at least the arguments that users and maintainers have over SemVer is broken.

pabs3 5y ago

My favourite version system is PiVer, where you start with version 3.1 and then progressively add more digits from Pi. IIRC one of Joey Hess' projects did this.

mybrid 5y ago

Versioning is marketing. This is just the latest Coke Zero. Anything public facing is marketing. I remember when marketing got ahold of memory and disk size in the 1980s Then it was CPU size. Size matters. As someone once quipped, "If winning dosen't matter then why do they keep score?" Micrsoft can't release annually and Apple iOS can. That's a score. Marketing is about selling the sizzle and not the steak and versions sizzle. Forget trying to make public meaning out of them. Sales can sell bigger is better.