Hacker News new | past | comments | ask | show | jobs | submit login
ZeroVer: 0-Based Versioning (0ver.org)
570 points by polm23 5 months ago | hide | past | favorite | 262 comments

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.

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.

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.

> I'm a one man shop though so I never branch for major/minor releases.

Honestly, for my one-man projects I use 0. to indicate "there is absolutely no backwards compatibility guarantees because I'm still fucking around" and 1. to indicate "this is in prod and I'm confident about it" (with attendant discipline on how semver major/minors are supposed to be used).

Yes, and 2 is "I probably broke your favorite API."


That's regular Semantic Versioning


> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

> Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

> If your software is being used in production, it should probably already be 1.0.0.

Basically, nobody wants to deal with backcompat. Having worked somewhere where we supported stuff more than a decade old, it's not entirely surprising. It's really hard to know what crazy stuff customers are doing with your stuff, and fun new things often die off during the pitch.

think of react-native being used in production for years while it's in 0.x.x

Ask me how I can tell you haven't been using this strategy for more than a decade or two. ;)

I say that mostly jokingly, but stuff like this was really annoying around the turn of the century, in a death by a thousand cuts kind of way.

Please, just put the full year in. It's only two more digits, and will prevent the older people that see it from building a little bit of rage up every time they see it.

I've been using it for over 20 years...

Y2K100, aye!

Or even trying to determine which value represents year, month, or day. Internet date format is the only way to go, IMO.

This works well only if you're supporting a linear evolution of releases, no branching or LTS or back-porting.

There’s nothing that says you can’t have patches in calver, as e.g. `YY.MM.patch`. So you can definitely have an LTS calver release, or even back port new features. You just have to do it in the patch version, or adopt some other variation of the scheme, e.g.`YYYY.minor.patch` or `YY.MM.minor.patch`

Yep. This is what Ubuntu does, roughly. Version 2020.04 is LTS and will get security updates until 2030 April (04)

This is the exact strategy we use for our rollouts too. 2021-08-12.01 was just released.

minor/major makes sense for, when a company plans to support a major for longer period of time, if the development is continuous, the date sounds good

I've come to the same conclusion for the main product which always moves forward and currently has limited and tightly coupled relations. If the product gets lots of external consumers, then making it more versioned might make sense.

But for common libraries SemVer feels good solution for not breaking the main products and helps making developers to think about breaking changes etc.

What are you going to do when it is August 11th 2121? Reuse the build number?

Add a 1. in front. It earned it.

not a problem. it's physically impossible for any software to be maintained that long.

you can't prove me wrong

Sure I can. It will just take some time to do so.

If the project actually does last that long, I'm sure it wouldn't be hard to just extended the version by 2 digits to include the full year.

You mean that you're _sure_ that nothing will be dependent on the format of the version string of a >100yo project?

I'd bet everything I own against that

Is it a Mozilla project because that is some Mozilla type version inflation?

Instruct the AI to move the project to a versioning system that supports full calendar year.

This is a solved problem.

[Y2K Programming solutions]: https://en.wikipedia.org/wiki/Year_2000_problem#Programming_...

This is what makes sense to me as well.

It is also much easier to reference when talking with other devs, users, etc.

We all know the calendar and a date is much easier to remember.

Straight increases 5, 6, 7 ar also easier for user to reference.

That's what Jetbrains does

Unfortunately I've found there often needs to be separate internal and external version numbers.

An internal rewrite where all the "old bugs" are fixed, but minimal new features are added may feel like a 2.0 for those who worked on it, but for external customers it's the same tool, with the same functionality, just maybe looks a little different.

A 2.0 is often heralded with marketing fanfare, so it needs justification.

I'm not saying it's right, or that one rule fits all; I've seen it first hand and feel your pain.

And on the flip side, sometimes internal version 11.3 is a boring release with only small changes since 11.2, but if one of those changes was a feature that marketing cares about then bumping to The New Exciting 12 may be in order.

Opposite(?) example is Windows NT 5.1 / 6.1

I have seen completely opposite things in my previous startup I worked for. The product wasn't event production ready, they would call it version 1.0, version 2.0 and now version 3.0

Versions were bumped now and then, without real major changes.

They use this as marketing gimmick to create buzz that something major is being released but actually it was same old stuff just not ready for primetime.

It is so weird how many people seem to have a stake in the version number. Personally I'm all for date or build numbers, and removing version numbers entirely

Yeah, after 1.x, the 2.0 is one last savior. Beyond that, there is no hope.

Worth noting that this page is satire and poking fun at many of the issues that you note here.

Yeah zerover seems kinda Draconian like “you’ll never be good enough!”

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

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

Then don't use that software if prod if that’s how you feel. The project is literally telling you “this will change and isn't _api_ stable yet. I don’t see how that’s the project’s fault. Maybe if they’re advertising themselves as production quality but won’t commit to a 1, fine.

What is there to commit to though? There are enough integers to keep bumping the major version every day indefinitely if that's how often your api changes. Also, no one forces you to support 'deprecated' versions, and the rate of deprecation is completely in the hands of maintainers. It's just nice to have some indication of what's going on between versions.

If something is 'production ready', it's definitely past the '0.y' stage by definition. At least if you actually stick to semver, as '0.y' is explicitly defined as reserved for initial development.

Because a major version of 1.0+ carries the social implication of updates and stability, even if that's not written in the SemVer spec. Many projects want to avoid even the impression of stability

This is fine, as long as those projects don't also encourage people to use them in docs and fancy marketing websites. That's just double faced.

So let’s say you start a project, get 70% there, it’s version roughly 0.7. The project blows up, people get interested, lots of attention is paid to the periphery. Everyone is now using your project but it’s still missing 30% of what you’d consider necessary to be feature complete. What do you do?

That's the big misunderstanding here, isn't it? That software must be 'done', 'finished', 'feature complete', etc, in order to have major version number greater than 0.

I would (I hope), release version 1.0 soon after I notice people actually using the software, document the existing API, keep releasing new features as minor version updates (1.x), and occasionaly do a major version bump if I see that I must break the existing APIs. As semver prescribes.

Do you think that's appropriate for React Native? Many of the others on their list of notable projects would probably be considered "production" quality if you asked the average dev and didn't mention the version number.

I would think that's appropriate for React Native. It depends where you draw the line of "production-ready", but React Native falls short on a number of criteria (stability or bug-freeness for example). It's just a damn useful tool, despite its many shortcomings.

to me production-ready means ready to be used in production; If you and many people consider it useful enough to be used in production despite shortcomings, and are doing so, if the developers are aware of that and don't discourage it (does any react native documentaiton anywhere say not to use it in production?), and perhaps encourage it... it sounds production-ready to me.

So other people are the only ones who know when my project is done? And if people start using my project in production I have to immediately bump the version from 0.4 to 1? This doesn't make any sense…

Right, I'm with you. I think maybe the whole "we should all version the same way" thing probably isn't the right answer to "how do we know when it's safe to upgrade" question.

OP: I have issues with the phrase "open-source devs don't owe you anything"


Come on, at least try to engage with what's being said.

That’s not what I said, maybe ready my comment again.

OP: I have a problem with open source projects where the marketing and version number don’t match. If it looks like a prod, and smells like a prod, it’s a freaking prod. You owe us a 1.0.

Reply: Okay, but maybe don’t go gobble up any project out there that has a nice landing page and docs and get fooled into thinking it’s a prod. The devs are probably using semver to try and communicate with you. If the project smells like a prod to you but is only version 0.8 and that makes you antsy, then don’t be part of your own problem. Don’t use it in prod. Simple.

Also plenty of software is stable enough to be used as 0.8 even in prod even if it’s not feature complete and the maintainers don’t consider it 1.0.

If you want your 0.8 to magically become a 1.0, have you considered sponsoring the project so that some devs can work full time on it? Hmm.

From the About page:

> ZeroVer is satire, please do not use it.

Unfortunately, from the main page it's clear everybody does anyway.

> open source maintainers owe you nothing and you should expect nothing of them

I tend not to release projects just because I think people should expect something from me if I do.

On another note, I'm totally down to accept that OSS projects be malleable, but it does irk me when someone:

1. brags a ton about their project just to find it's really not that great or

2. changes things with almost no concern for who it will affect and how or

3. refuse to change things for some ideological reason when tons of people are asking for it ("that's not the right way to do it!" "you don't know my project")

You never have to use a 0.x-version package even if "everyone" is using it, this is like another ultimate HN "I'm forced to do what everyone else is doing and I hate my own choices". If it's just an indirect usage via dependency of a stable package, then it doesn't matter, the stable package itself is responsible for its stability.

We use open source because through either corporate incentive or altruistic passion, some packages do put in the effort to meet user needs. That happens whether you think they owe you anything or not, which they don't. All you achieve by raising the floor of expectation is discourage non-production-ready open source contributions, which I think are still valuable regardless of how unstable they may be.

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

God forbid tor, sklearn, react-native release a v1 -- people might expect things!

OpenSSL went to double-letter patch versions in their 0.9.x days, for example 0.9.8zh.

> OpenSSL went to double-letter patch versions in their 0.9.x days, for example 0.9.8zh.

They only used single letters:

* https://www.openssl.org/news/changelog.html

The IEEE Ethernet standards are using double letters though:

* https://en.wikipedia.org/wiki/IEEE_802.3

> They only used single letters:

> * https://www.openssl.org/news/changelog.html

From that link:

> When a release is created, that branch is forked off, and its changelog is also forked. For example, none of the changes after 0.9.8n appear in the other logs, because 1.0.0 was created after that release and before 0.9.8o.

If you look at the changelog in the v0.9.8 branch, you'll see they got up to 0.9.8zh:


Who were you, Denvercoder9? What did you see?

The legend of Denvercoder9 continues to this day

ReactOS existed for 25.5 years, now on version 0.4.13.

Tor has been around for 17.3 years, now on version

Seems getting rock-solid software to >1.0 takes a rock-solid effort.

ReactOS makes sense to still be at version 0. Even with all the work put into it, it's still not usable as a daily driver.

For React Native we do ~monthly releases and just increase by 1 each time. It’s a train model this way people know when their changes will get released. I guess we should consider bumping to 1.x at some point and keep going :)

Monthly? There were 3 releases in 2019, 2 in 2020, 2 so far in 2021 if you count the imminent 0.65 release.

I guess maybe it's monthly if you count the patch releases? But you can't really claim to "just increase the number by 1 each time" when you have two separate numbers which get incremented for different reasons.

I haven’t worked on React Native for many years now… looks like it has slowed down! It was monthly in the first few years.

Skip 1.0 and 2.0 to brake people's expecting.

Like at some point just e.g. move from 0.69.0 to some arbitrary number like 7.0.0 or even 70.0.0.

Java did that, right? From Java 1.4 to Java 5.

Also, at $WORK we have three separate but related products, each with separate version numbers that we jumped at some point to reach the same value across all 3. One of the products jumped from 3.x to 9.0 I believe.

Java 5 was still v1.5, except for marketing, iirc. The 1.x versions persisted internally for a few releases.

Java moved from 1.4 to 1.5 and just stopped displaying the 1.

The reason was that they committed to never to any "major braking change" i.e. that there would never be a version 2.

At the same time the backwards compatibility guarantees didn't work always as good as some people liked so they decided to move from semver to something which is like "only do minor releases, but sometimes imperfect making them somewhat major releases but also somewhat not".

What I advocated for differs in that I want to keep semver. So when you move from e.g. 0.32.0 to 32.0.0 you still would only inc minor version for non braking changes and the patch version for patches.

Through this means that you now can denote path updates, as in 0.32 the minor updates are like major updates and the patch updates are like minor updates.

This can be especially useful when development release speed slows down and you want to make a new release with e.g. just fixing some API docs or just non API exposed bug fixes.

Java / OpenJDK never used semver in the first place. Also, large projects like Java have entire layers of different APIs, whose compatibility guaranties can't really be described with a single number, no matter what versioning scheme they use.

why not switch to a year-month then, if the release process is already time-based?

1. cost (and risks) of switching - not just for the project itself, but across the ecosystem and all the millions of users

2. what if you need multiple releases in a month, in a day?

3. if it works, don't touch it

i dont have awnsers for 1 and 3 but reagarding 2 the format YYYYMMDD.NN allow you to have 100 releases a day...

Do you have any policies around backwards compatibility? Is there any way to know if a given release has intended backwards-breaking changes or not?

yup sounded like a joke until the table LOL

(Just wanna make it clear that this is a joke. The footer says published April 1 and the about page states it is satire just for anyone confused.)

I don't think calling it a joke is correct. It correctly self-describes as satire, which is quite different. Both use humor but one is not meant seriously whereas the other has a serious critique behind it.

A good satire should have a serious point it dismisses as part of the joke. For example Swift's "A Modest Proposal" is famous for its recommendation that Ireland's problems will be solved if the Irish eat their children, but it explicitly dismisses the possibility of taxing "absentee landowners" and other wealthy people and that is what Swift thinks you should actually do.

The closest ZeroVer comes is to quote Tom Preston-Werner, "If your software is being used in production, it should probably already be 1.0.0." which is something, but could perhaps be dismissed more thoroughly as undesirable or mistaken in this document.

> For example Swift's "A Modest Proposal" is famous

Given the context, I thought for a minute that you were talking about Apple's presentation of the rationale for a successor to Objective-C.

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.

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

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.

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

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

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!

No no, you have a point, gotta agree. I have my own project and I always know which is my latest version, it is: a11bef06a3f659402fe7563abf99ad00de2209e6

edit 1: (sorry wrong one) 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7

edit 2: (ahh, sorry again, this is my latest version) a11bef06a3f659402fe7563abf99ad00de2209e6

edit 3: (this is the one, definitely) ca82a6dff817ec66f44342007202690a93763949

Too complicated, just generate a UUID.

I find git commit hash too long for no good reason.

I prefer to version with the file size, which is strictly increasing if you follow those best practices:

- never delete any of your valuable code (commenting out is OK)

- never break up code into several files (makes it simpler to read).

> - never delete any of your valuable code (commenting out is OK)

So how does this work if you want to change a line in a function? Do you just comment out the line and write a new version below it? i.e. if I want to fix a bug in my code, I can't just fix it, I have to add a line of code to my program.

How does this system work in practice? The way I code, it seems like this would lead to a huge file that is mostly commented.

I think it is meant to be a joke like ZeroVer.

You change the line, and add a comment explaining what the code used to do?

This, or add another cat photo to assets

I hope you are making a joke, if not, you will be overjoyed when you find a source control system and can tidy your source file.

Some useful commands for making this more friendly:

Get the number of commits with `git rev-list --count HEAD`.

Get a label that uses the most recent tag plus the number of commits since and the current commit hash with `git describe` (read its documentation, it’s got a few nice knobs to match whether you use unannotated tags, annotated tags, branches, &c.).

This sort of thing is used in Arch Linux packages based on Git repositories, things like this:

  pkgver () {
    cd the-git-repository
    git describe --long 2>/dev/null | sed 's/\([^-]*-g\)/r\1/;s/-/./g' || \
      printf "r%s.g%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
… which will give you versions like “1.2.3.r45.gdeadbeef” for commit deadbeef which is 45 commits past the one tagged 1.2.3, or “1.2.3.r0.g01234567” for commit 01234567 which is tagged 1.2.3, or “r1234.gdeadbeef” where you have no tags and 1234 commits from the root(s) until HEAD which is at commit deadbeef.

That's missing the point of release versions. Git commits are not obviously ordered (you need access to the repo to do this), they don't tell you if it's a small patch release or a huge change.

Contrast: v0.4, v1.0, v1.0.1, v.1.5 versus a bunch of SHA-1.

And have no idea how recent the version is unless you have immediate access to git. It’s a very engineer-centric idea.

Really handy to communicate verbaly or promote.

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

Perhaps this is a joke I’m not getting in which case I apologise.

The advantage of semantic versioning (SemVer) over git hashes is… well… semantics. You can immediately identify if the next version introduces a breaking change, for instance. This without mentioning ordering, and being easily able to tell versions apart - e.g: which (if any) versions are different in these three versions?

c26cf8af138955c5c67cfea96f9532680b963628, c26cf8af130955c5c67cfea96f9532680b963628, c26cf8af130955c5c67cfe9a6f9532680b963628

You can get easy check-outs and git-logs by using git tags for each version.

Versioning scheme without an ordering is usually pretty bad idea. Also, try telling your colleague which version she needs to install... Might as well give up on communicating by anything but Slack.

> Never worry about which digit to increment (denver, 0ver)

Yay, every version is a patch and who cares if there's breaking changes.

So now I need full QA before I pull in every security patch: a lovely idea in theory but in practice it's just a major motivator for engineers to leave their dependency tree to grow horribly out of date and littered with known vulns.

> ... or what date it is (calver) because who remembers the date.

Have to agree with this though, calver is pointless.

All it does is caters to the general bias people have toward "new is better" and "well maintained = frequently added new features", neither of which are true.

> who cares if there's breaking changes.

Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users. Anecdote: Just yesterday our entire CI process was taken down due to a bump in the AWS ebcli package from 3.20.0 -> 3.20.1. This should have been a non-breaking change, but instead resulted in an entire days worth of release management being grinded to a halt.

Pin your versions. Test all upgrades.

An anecdote about one time the system failed (yes we're human, nothing is ever applied perfectly), followed by the very simple suggestion that we instead all comprehensively and completely test every patch release of every dependency in our chain (we'd all like to but see above about humans and perfection).

Semver brings net benefit for the times when it is applied correctly. For the rest, we do our best to test as much as we can.

The advice is to not just willy-nilly just pull in the latest patch releases just because it's "supposed" to work. Regularly testing and updgrading at _least_ your core dependencies should be part of the day job of any competent team. If you have too many dependencies to have capacity to do this on an ongoing basis - maybe you just have too many dependencies. Excuses don't make the problem go away.

Just assuming you can upgrade something from 3.20.1 over 3.20.0 because it just happened to release 9 hours ago is a recipe for disaster. Pin your version to 3.20.0 - regularly review your dependencies, upgrade and test - THEN roll it out system wide. Don't just assume something is going to work and roll it out to everyone without checking because some arbitrary versioning scheme says it should.

Be thoughtful. Methodical. Consistent.

> Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users.

You are misunderstanding the scope of SemVer. It's purely about intentional changes to public interfaces. It should go without saying that no versioning scheme can ever hope to indicate whether or not new bugs have been introduced or uncovered that impact your consumer of said interface, nor can it possibly anticipate potential bugs in consumers that could be triggered by any changes that result in valid but previously unseen data being returned. It also doesn't say anything about the update process itself. If an update fails in such a way that your consumer can't use the interface that has nothing to do with the version number.

No one reasonable has ever claimed that SemVer could allow you to just YOLO your updates without testing. When implemented properly it provides a comfort level for updates that should give you an idea of how closely you should look at the changes being made and how they might impact whatever you have consuming that interface.

> Have to agree with this though, calver is pointless.

I've found calver useful for applications. It makes it clear how old the version you're running is. IntelliJ and Windows both use it and I prefer it to a version number you have to look up.

Yes actually, you're right. Arguments for semver aren't really applicable to user-facing stuff as upgrades there are tested by release teams and generally in most cases you want users to upgrade always.

The utopian ideal for apps in cases where someone might choose to use an older version (presuming LTS) would be somehow naming the release based on features, but that's not practical so date-based versioning is a really good proxy here.

Calver's uselessness only really applies to software dependencies.

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.

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

> the commit hash being a checksum of the commit contents will never change for the same commit

It will if the parent changes, for example on a rebase. Now, it is up to discussion on whether that is a different commit (technically the parent hash is part of the commit), but most people probably consider the content changes to be the actual commit.

Then most people are wrong. We already have a word for the content changes: a patch. A commit is a patch applied on a previous state. (Or for git, a snapshot with zero or more previous states if you want to be pedantic.)

If you google what is a git commit, almost nobody points this specialty out. This is also most likely what the above comment got wrong.

So I don't disagree with you; if we're being pedantic, the commit hash never changes for the same commit [0]. I just pointed out that what someone without an in-depth knowledge of git would intuitively consider to be a commit can indeed have changing hashes.

[0] There does not seem to be an authoritative definition for the git-type of commit, so I guess we need to go with "a commit is what git considers a commit".

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

Too bad the "article" is written in 2018 and Hashicorp release Vault 1.0.0 December 3rd, 2018 :)

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.

It seems HashiCorp got the message ;)

Kafka part is brilliant, too bad they went to the dark side with 1.0 release in 2017.

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

Humour is wasted on Hacker News.

this is my favorite comment.

ZeroVer is satire [1].

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

...and so it's explicit... the homepage's table of projects is a Wall of Shame.

Thank you... I couldn't understand the reason to use it.

It's so you can tell your users that the bugs aren't going to be fixed yet. It'll be ready by v1.

I would say that it is more about avoiding to promise anything about API stability between versions.

and you can break the api anytime

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

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

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"?

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.

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

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

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

"Peter Pan versioning"

This really should be the term for projects that are perpetually releasing 0.x versions.

Maintainers are free to release their software under whatever terms that they wish, but if you actively encourage people to use your software and do not want to maintain backwards compatibility, then IMO, you should be very honest about that.

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.

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.

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.

> It effectively says "meaning doesn't exist".


It says that there's no universal agreement on this one thing, and while if you want to sell to certain people you should tailor your versioning appropriately, there's zero point in assuming a single interpretation. If I use CalVer some people who think there's only one way to do this may assume the product has had 2021 major version releases.

That would be a silly assumption.

Once a project has been out for years, and has thousands or millions of users, it's not in the experimental phase any more, regardless of what the version number claims.

Similarly to https://www.hyrumslaw.com

It has nothing to do with experimental status; rather, some efforts like React Native concern platforms that constantly introduce new OS versions with new and deprecated APIs. It doesn’t make sense to pin versions to device generations when there are half a dozen different vendors to account for: if changes to one platform mandate breaking changes, all platforms would be affected anyway, and any platform can change at any time. Since new devices are first adopted by people with lots of money, developers have an incentive to stay as current as possible, so the point of pinning to device versions or generations is completely moot.

In semver terms that means increasing semver-major. Instead of 0.x.y you do x.y.z. There's no rule in semver that says you need to stay on 1.x forever.

It’s just that version 724.1.2 might look weird in some eyes.

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

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

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.

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.

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.

There won't be any breaking API change until the next major version. Nothing in semvet prevents you from having releases 1, 2, 3, 4 instead of 0.1, 0.2, 0.3, 0.4. At some point you can just drop the zero and carry on, it's false to say that you can't make breaking changes after 1.0.

I feel like this is meant to be satire, but I wonder if there's some truth to it

Yes and yes. But isn’t that kind of the point of good satire?

Yes. From my perspective one benefit of 0 major version in 1-person OSS projects is it gives a clear signal that "yes this code is available for you, but no I'm not an enterprise support solution, I'll do what seems useful/relevant to me when I have time and when it feels relevant".

That doesn't mean intentionally breaking backwards compatibility but also this isn't my paid day job so I might do it and I'm not going to spend my evenings compiling release notes / migration guides for free.

In this way it's an effective anti-big-corp shield since a lot of enterprises have dumb rules about using beta/alpha versions. I think it's a strong signal where people can't just use a beta or pre-release version of some code that they're a) not auditing their dependencies and b) probably work somewhere that has the money to pay for that level of service but just want you to do it for free.

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.

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.

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.

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

This is true no matter what you name your versions, I don't know what you are saying.

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.

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

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

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.

I've always wondered if windows 3.11 was not meant as a minor upgrade of 3.1, but they assumed versions are a float so 3.1.1 was out of the question. There is AFAIK no windows 3.2 to windows 3.10

One reason I think adding the third component is useful. At least 1.10.0 is clear you aren't looking at an ordinary decimal point number.

There are also plenty of humans (and software) that will change x.y.z to x.yz

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.

There are plenty of countries outside the US that don't use '.' as a date separator.

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

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.

What locale is that? I know that e.g. de-DE uses trailing dot to mark ordinal numbers, so "1." means "the first", but it also uses decimal comma instead of decimal point, so there is no confusion.

TBH, I'm German, but a Software Engineer, so it's a mix of both.

I don't know what an average German would make of "1.10", really. I've only seen that as "subsection 10 of section 1 of a book".

How would October 1st be written down at your place?


Ah i see, the trailing dot.

That's actually a good idea. It takes away all the stress over deciding if some released thing is ready (for what?, anyway, it's not up to you to decide), and removes the stupidity of "semver does not apply if it starts with a zero".

Bijective base 10 versioning!

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

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.

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.

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.

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

2: https://github.com/hashicorp/terraform-provider-azurerm

3: https://github.com/hashicorp/terraform-provider-aws

4: https://github.com/hashicorp/terraform-provider-google

5: https://github.com/hashicorp/terraform-provider-azurerm/pull...

Yes, you're complaining about provider problems. All terraform does is translate HCL into commands against the providers' own APIs. Right around the transition periods between 0.11 through 0.14, AWS, Google and Azure were rewriting large sections of their own public-facing APIs, changing tons of behaviors and then rewriting their Terraform providers to match the API changes.

That's an issue with those providers' APIs and how their Terraform provider was architected. Most of the other Terraform providers were smooth-sailing during the same period, save for the major challenges involved in updating 0.11 to 0.12.

You're putting the blame in the wrong place. In the case of all three of those cloud providers, the companies' own employees plus outside contributors maintain the terraform providers, not HashiCorp. HashiCorp gets involved but mostly to resolve errors in Terraform itself.

Saying they are maintained by HashiCorp is completely incorrect. They are part of HashiCorp's repos (because they are official) but in each case the core contributors are people from AWS, Azure and Google.

My company has large accounts with all of these, I contribute to them myself and I know(/knew. Dana @ Google moved onto another role and Google hasn't introduced me to her replacements yet) the maintainers of all of them personally. Don't look at who owns the repo, look at the contributor lists.

I don’t see why I, the end user, should be forced to make that differentiation since Terraform is effectively useless without the providers from the big three. Statements like “you’re blaming the wrong people” is in the same spirit as what ZeroVer is lampooning.

Like yes, our internal provider was a pain point and we own that but the rest of the drama around providers was just weird. The work to move over 200 repositories through the hoops to keep them updated, especially mature services that may not have been deployed for several months, was difficult to automate and very brittle even when it was.

It broke down at scale and really no one should have been using it that wide spread before it was 1.0.

Hashicorp’s whole treatment of terraform 0.x was horrendous and constantly broke everything, all while they said it was production ready. You can blame whoever you want but the total lack of stability and easy upgrade paths and constant manual fiddling and reviewing output from ‘upgrade0.11’ type commands was ridiculous and a massive time sink for our org.

I've written more Terraform than most people outside of possibly the folks at HashiCorp themselves and probably Gruntwork. Have been using it at 10^5 scale of systems and haven't had nearly the kind of problems that you're describing.

Also the treadmill is really not any different than integrating with _ANY_ Google service. In fact I'd say it's an order of magnitude better. Google has set a standard of breaking changes without notification and if that's one of the providers you're using then I understand.

And well, if it was Azure (as it likely looks to be) the state of their public facing APIs is/was an absolute fucking mess and the preferred way to do anything in their system still seems to be using the UI. I've talked to several people at Microsoft at Azure teams responsible and there's multiple compounding problems there. For one you have 200+ engineering teams with no unified approach to exposing services. Then you've got multiple regions in their cloud that for years didn't have the same authentication system, didn't have consistent features between regions, etc.

There's very little you can lay at Hashicorp's feet for this when the underlying systems themselves have very poor automation.

And then you talk about having 200+ repos and services that haven't been deployed for months and all I can say is the consensus around the need for CI/CD is over a decade old now and infrastructure needs these things just as much as code does.

100% of my Terraform is in a CI/CD pipeline. Yes it was a lot of work to set up, but the alternative is nothing but problems. Terraform is just a tool. It's not a panacea. It will not make all of your problems go away -- it's up to the craftsman how good it is.

Looks like fail2ban (16.8 years of being zero-versioned according to this site) is actually on the path to a 1.0 release:


Well, the master branch is considered 1.0 at least. Not sure if there's been an official 1.0 release though...

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.

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.

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

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.

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

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.

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

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

Neovim is listed as a "notable ZeroVer project" and yet it has a 1.0(!!) milestone in the GitHub project page.


> 0% complete

> No due date

> Last updated over two years ago

Looks like a classic case of ZeroVer!

Replace “case” with “practitioner” please. It’s not a disease!

Are you sure about that?

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.

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.

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

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.

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact