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
... 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.
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.)
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 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.
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.
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.
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.
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!
> 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:
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!).
I don't think calling it a joke is correct. It correctly self-describes as satire, which is quite different. Both use humor but one is not meant seriously whereas the other has a serious critique behind it.
A good satire should have a serious point it dismisses as part of the joke. For example Swift's "A Modest Proposal" is famous for its recommendation that Ireland's problems will be solved if the Irish eat their children, but it explicitly dismisses the possibility of taxing "absentee landowners" and other wealthy people and that is what Swift thinks you should actually do.
The closest ZeroVer comes is to quote Tom Preston-Werner, "If your software is being used in production, it should probably already be 1.0.0." which is something, but could perhaps be dismissed more thoroughly as undesirable or mistaken in this document.
For React Native we do ~monthly releases and just increase by 1 each time. It’s a train model this way people know when their changes will get released. I guess we should consider bumping to 1.x at some point and keep going :)
Monthly? There were 3 releases in 2019, 2 in 2020, 2 so far in 2021 if you count the imminent 0.65 release.
I guess maybe it's monthly if you count the patch releases? But you can't really claim to "just increase the number by 1 each time" when you have two separate numbers which get incremented for different reasons.
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 moved from 1.4 to 1.5 and just stopped displaying the 1.
The reason was that they committed to never to any "major braking change" i.e. that there would never be a version 2.
At the same time the backwards compatibility guarantees didn't work always as good as some people liked so they decided to move from semver to something which is like "only do minor releases, but sometimes imperfect making them somewhat major releases but also somewhat not".
What I advocated for differs in that I want to keep semver. So when you move from e.g. 0.32.0 to 32.0.0 you still would only inc minor version for non braking changes and the patch version for patches.
Through this means that you now can denote path updates, as in 0.32 the minor updates are like major updates and the patch updates are like minor updates.
This can be especially useful when development release speed slows down and you want to make a new release with e.g. just fixing some API docs or just non API exposed bug fixes.
Java / OpenJDK never used semver in the first place. Also, large projects like Java have entire layers of different APIs, whose compatibility guaranties can't really be described with a single number, no matter what versioning scheme they use.
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.
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.
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.
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.
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?
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.
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.
I have no idea how you or your parent immediately arrived at calendar dates (which in my book require a period at the end), but to everyone i know, 1.10 is not a date, but a floating point number with the same magnitude as 1.1, which is thus closer to 0 than 1.9 is.
What locale is that? I know that e.g. de-DE uses trailing dot to mark ordinal numbers, so "1." means "the first", but it also uses decimal comma instead of decimal point, so there is no confusion.
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
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".
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!
This is incorrect. You can create a new commit with a different hash, but the commit hash being a checksum of the commit contents will never change for the same commit.
> the commit hash being a checksum of the commit contents will never change for the same commit
It will if the parent changes, for example on a rebase. Now, it is up to discussion on whether that is a different commit (technically the parent hash is part of the commit), but most people probably consider the content changes to be the actual commit.
Then most people are wrong. We already have a word for the content changes: a patch. A commit is a patch applied on a previous state. (Or for git, a snapshot with zero or more previous states if you want to be pedantic.)
If you google what is a git commit, almost nobody points this specialty out. This is also most likely what the above comment got wrong.
So I don't disagree with you; if we're being pedantic, the commit hash never changes for the same commit [0]. I just pointed out that what someone without an in-depth knowledge of git would intuitively consider to be a commit can indeed have changing hashes.
[0] There does not seem to be an authoritative definition for the git-type of commit, so I guess we need to go with "a commit is what git considers a commit".
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
> - 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.
> 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.
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.
An anecdote about one time the system failed (yes we're human, nothing is ever applied perfectly), followed by the very simple suggestion that we instead all comprehensively and completely test every patch release of every dependency in our chain (we'd all like to but see above about humans and perfection).
Semver brings net benefit for the times when it is applied correctly. For the rest, we do our best to test as much as we can.
The advice is to not just willy-nilly just pull in the latest patch releases just because it's "supposed" to work. Regularly testing and updgrading at _least_ your core dependencies should be part of the day job of any competent team. If you have too many dependencies to have capacity to do this on an ongoing basis - maybe you just have too many dependencies. Excuses don't make the problem go away.
Just assuming you can upgrade something from 3.20.1 over 3.20.0 because it just happened to release 9 hours ago is a recipe for disaster. Pin your version to 3.20.0 - regularly review your dependencies, upgrade and test - THEN roll it out system wide. Don't just assume something is going to work and roll it out to everyone without checking because some arbitrary versioning scheme says it should.
> Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users.
You are misunderstanding the scope of SemVer. It's purely about intentional changes to public interfaces. It should go without saying that no versioning scheme can ever hope to indicate whether or not new bugs have been introduced or uncovered that impact your consumer of said interface, nor can it possibly anticipate potential bugs in consumers that could be triggered by any changes that result in valid but previously unseen data being returned. It also doesn't say anything about the update process itself. If an update fails in such a way that your consumer can't use the interface that has nothing to do with the version number.
No one reasonable has ever claimed that SemVer could allow you to just YOLO your updates without testing. When implemented properly it provides a comfort level for updates that should give you an idea of how closely you should look at the changes being made and how they might impact whatever you have consuming that interface.
> Have to agree with this though, calver is pointless.
I've found calver useful for applications. It makes it clear how old the version you're running is. IntelliJ and Windows both use it and I prefer it to a version number you have to look up.
Yes actually, you're right. Arguments for semver aren't really applicable to user-facing stuff as upgrades there are tested by release teams and generally in most cases you want users to upgrade always.
The utopian ideal for apps in cases where someone might choose to use an older version (presuming LTS) would be somehow naming the release based on features, but that's not practical so date-based versioning is a really good proxy here.
Calver's uselessness only really applies to software dependencies.
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.
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?
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:
… which will give you versions like “1.2.3.r45.gdeadbeef” for commit deadbeef which is 45 commits past the one tagged 1.2.3, or “1.2.3.r0.g01234567” for commit 01234567 which is tagged 1.2.3, or “r1234.gdeadbeef” where you have no tags and 1234 commits from the root(s) until HEAD which is at commit deadbeef.
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.
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.
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.
” 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.
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.
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`
> 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).
> 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.
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.
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 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.
Unfortunately I've found there often needs to be separate internal and external version numbers.
An internal rewrite where all the "old bugs" are fixed, but minimal new features are added may feel like a 2.0 for those who worked on it, but for external customers it's the same tool, with the same functionality, just maybe looks a little different.
A 2.0 is often heralded with marketing fanfare, so it needs justification.
I'm not saying it's right, or that one rule fits all; I've seen it first hand and feel your pain.
And on the flip side, sometimes internal version 11.3 is a boring release with only small changes since 11.2, but if one of those changes was a feature that marketing cares about then bumping to The New Exciting 12 may be in order.
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
273 comments
[ 665 ms ] story [ 3861 ms ] thread[1] https://0ver.org/about.html
(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.)
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.
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.
Similarly to https://www.hyrumslaw.com
That made me laugh out hard :D
https://github.com/neovim/neovim/milestones
> No due date
> Last updated over two years ago
Looks like a classic case of ZeroVer!
God forbid tor, sklearn, react-native release a v1 -- people might expect things!
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
> * 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...
I think, it's a sign of hybris if a project owner goes 1.0 too soon.
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"
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 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.
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.
2. what if you need multiple releases in a month, in a day?
3. if it works, don't touch it
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
> 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.
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).
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 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".
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!
Eventually people will start random commits like "random commit to change hash" when commits accidently result in racist or taboo terms lol
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.
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.
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".
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
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).
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.
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.
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.
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.
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.
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.
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.
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.
Contrast: v0.4, v1.0, v1.0.1, v.1.5 versus a bunch of SHA-1.
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.
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:
… which will give you versions like “1.2.3.r45.gdeadbeef” for commit deadbeef which is 45 commits past the one tagged 1.2.3, or “1.2.3.r0.g01234567” for commit 01234567 which is tagged 1.2.3, or “r1234.gdeadbeef” where you have no tags and 1234 commits from the root(s) until HEAD which is at commit deadbeef.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.
” 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.”
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...
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.
I'm a one man shop though so I never branch for major/minor releases.
I'd bet everything I own against that
you can't prove me wrong
[Y2K Programming solutions]: https://en.wikipedia.org/wiki/Year_2000_problem#Programming_...
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).
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.
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.
But for common libraries SemVer feels good solution for not breaking the main products and helps making developers to think about breaking changes etc.
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.
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.
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.
*edit: yes, published 1 april 2018
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