ZeroVer: 0-Based Versioning(0ver.org)
0ver.org
ZeroVer: 0-Based Versioning
https://0ver.org/
273 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.
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.
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
What are you going to do when it is August 11th 2121? Reuse the build number?
Add a 1. in front. It earned it.
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.
Is it a Mozilla project because that is some Mozilla type version inflation?
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
I'd bet everything I own against that
[deleted]
[deleted]
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_...
[Y2K Programming solutions]: https://en.wikipedia.org/wiki/Year_2000_problem#Programming_...
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)
> 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).
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).
That's regular Semantic Versioning
https://semver.org/
> 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.
https://semver.org/
> 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
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.
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.
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.
But for common libraries SemVer feels good solution for not breaking the main products and helps making developers to think about breaking changes etc.
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 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.
That's what Jetbrains does
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.
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.
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.
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.
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.
Yeah zerover seems kinda Draconian like “you’ll never be good enough!”
[deleted]
Worth noting that this page is satire and poking fun at many of the issues that you note here.
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?"
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....
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.
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.
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"
Reply: OPEN-SOURCE DEVS DON'T OWE YOU ANYTHING!!!
Come on, at least try to engage with what's being said.
Reply: 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.
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.
> 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?
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?
> 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")
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.
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,
God forbid tor, sklearn, react-native release a v1 -- people might expect things!
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
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:
https://github.com/openssl/openssl/blob/OpenSSL_0_9_8-stable...
> * 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:
https://github.com/openssl/openssl/blob/OpenSSL_0_9_8-stable...
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 0.4.7.0
Seems getting rock-solid software to >1.0 takes a rock-solid effort.
Tor has been around for 17.3 years, now on version 0.4.7.0
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 :)
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
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...
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 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.
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?
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.
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.
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.
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.
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.
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.
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.
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"
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!).
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!
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!
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
Eventually people will start random commits like "random commit to change hash" when commits accidently result in racist or taboo terms lol
And have no idea how recent the version is unless you have immediate access to git. It’s a very engineer-centric idea.
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.
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.
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.
[deleted]
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".
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".
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
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).
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
Contrast: v0.4, v1.0, v1.0.1, v.1.5 versus a bunch of SHA-1.
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.
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.
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:
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)"
}
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.
> 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.
> 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 seems HashiCorp got the message ;)
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.
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
[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.
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".
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
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 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.
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
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.)
(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.
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".
No.
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.
No.
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
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 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.
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.
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.
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.
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.
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 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.
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.
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.
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).
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".
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.
How would October 1st be written down at your place?
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".
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".
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.
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.
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.
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.
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...
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.
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.
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.
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.
[deleted]
[deleted]
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/3f5c382a988bb21f...
Well, the master branch is considered 1.0 at least. Not sure if there's been an official 1.0 release though...
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...
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...
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.
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 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.
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.
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.
https://github.com/neovim/neovim/milestones
https://github.com/neovim/neovim/milestones
> 0% complete
> No due date
> Last updated over two years ago
Looks like a classic case of ZeroVer!
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
ZeroVer is versioning for perfectionists.
https://news.ycombinator.com/item?id=28089287
https://news.ycombinator.com/item?id=28089287
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.
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.
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.
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.
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.
True ancestor to this:
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.”
” 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.”
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...
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...
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"?
...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"?
I'd like to think 0.0.0 is when the idea is still in your head.
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.
“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.
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.
Wow, lol. I usually pick up on satire.
It’s just …it’s 2020-ish and it looked very aligned with various edgy opinions.
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
The entire site only has a single blog post.
Go figure.
The canonical URL is https://0ver.org/zerover_0_based_versioning.html
The entire site only has a single blog post.
Go figure.
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.
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.
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.
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.
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.
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
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
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.
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.
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/
[1] https://semver.org/
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.
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.
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.
{major release timestamp}.{minor release timestamp}.{last patch timestamp}, which winds up like: 1542051468.1576431468.1613410668
Very clear and easy for users to understand.
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!
Helmfile might be a good addition to the list: https://github.com/roboll/helmfile/releases/
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.
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.
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
(Full disclosure, this is my site)
I’ll continue using ChronVer. https://chronver.org
(Full disclosure, this is my site)
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.
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.
SemVer FAQ [1] specifically recommends starting with 0.1.0.
[1]: https://semver.org/#faq
[1]: https://semver.org/#faq
I always bump major even though we follow semver. I consider my contributions major no matter how small. No impostor syndrome here, sir. (/s)
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.
If it really bothers you, I could write a script that subtracts 1 from semver compatible version numbers on checkout, and increments on push.
A brutal admission that modern software is broken and that stability, predictability, and correctness is just too much to ask for.
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...
I was ready to lose it on what I perceived as more pretentious developer shit, then I realized it was satire thank the Ford.
[deleted]
On the other hand, I am also quite annoyed that some projects do yearly major version after 1.0.
I remember when you might worry about getting fired using alpha version code in production.
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).
For backends etc I like to use year.week.build: v2021.32.1 for today’s build.
[deleted]
ElasticSearch was pretty solid when it was under zerover
[deleted]
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?
How could they miss 0 A.D.!
Oh its a joke? Poe's law was in effect for me.
...wait, this is a joke?! ..right?
*edit: yes, published 1 april 2018
*edit: yes, published 1 april 2018
using the an ISO date with a release/beta/branch-name as a version number always make more sense to me...
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.
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.
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.
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.
If my CI says a patch release broke my build, I think "I should figure out why, and report the bug unless it's already reported. This is a debugging task. If I can find time to do it now, it would be contributing back upstream."
If my CI says a major release broke my build, I think "OK, I will put this aside and schedule time to deal with it based on how important it is to upgrade, maybe I'll take a peak at the release notes (breaking changes section) now to get a sense of what might have broken and how much work it might be." And reporting a bug upstream is unlikely to be part of the work.
It's important signalling that helps us all cooperate to produce stable software, not just our own software, but the open source ecosystem we (in the best case) cooperatively develop.
It's also just about the only sane way to manage indirect dependencies that might be depended upon by multiple activated things. Widget and Doodad are both used by my project, and both depend on Button. How do we figure out what version(s) of Button will be (are intended to be, sans bugs) compatible with both of them?
If my CI says a major release broke my build, I think "OK, I will put this aside and schedule time to deal with it based on how important it is to upgrade, maybe I'll take a peak at the release notes (breaking changes section) now to get a sense of what might have broken and how much work it might be." And reporting a bug upstream is unlikely to be part of the work.
It's important signalling that helps us all cooperate to produce stable software, not just our own software, but the open source ecosystem we (in the best case) cooperatively develop.
It's also just about the only sane way to manage indirect dependencies that might be depended upon by multiple activated things. Widget and Doodad are both used by my project, and both depend on Button. How do we figure out what version(s) of Button will be (are intended to be, sans bugs) compatible with both of them?
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.
Agreed.
And I definitely don't read release notes of all my dependencies, even indirect ones, every time I update any. I lock to major versions (and hope my dependencies do to for indirect dependencies), and only look at release notes if an update breaks a build.
And I definitely don't read release notes of all my dependencies, even indirect ones, every time I update any. I lock to major versions (and hope my dependencies do to for indirect dependencies), and only look at release notes if an update breaks a build.
Eh, I would contend that poorly done semver is still better than date (only) versioning. You can always have date and/or hash as part of the metadata string. As long as you are honest with your team, saying "these are a best-effort to follow semver" it's clear what you are doing. If you are sub-1.0 basically every release is a minor bump anyways.
I'm also a big fan of CalVer (https://calver.org/), though I think it totally depends on the context. I wouldn't want to write C++ libraries with it.
I find it funny that CalVer highlights Ubuntu as a good example.
I like Ubuntu when it uses its CalVer versions, but if I have to look for a specific package, I still have to check which one Xenial is after looking at the apt sources.
I like Ubuntu when it uses its CalVer versions, but if I have to look for a specific package, I still have to check which one Xenial is after looking at the apt sources.
For end user applications? Sure. But for libraries where API compatibility matters I think semver is superior.
I've to admit it: I read through it with increasing disbelief, feeling old and outdated, until I've reached the release date.
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
It’s like saying the UTF BOM does nothing. The 0. prefix tells you it’s an enlightened project.
I love the religious overtones on the post. All I can say is that the best option is probably to coexist.