I like Donald Knuth's approach to versioning. Each new release of TeX has one additional digit appended, the most recent version being 3.14159265. The version numbers asymptotically approach π, suggesting the code is converging towards (but never quite reaching) perfection.
Legend has it that when Knuth dies, he'll to change the version number to π exactly, at which point all remaining bugs will become features and the software will achieve perfection.
>My last will and testament for TeX and METAFONT is that their version numbers ultimately become $\pi$ and $e$, respectively. At that point they will be completely error-free by definition.
Theoretically, the version "number" in this case is technically not a number, because you wouldn't do any math operations with it, it's more like a string. So 3.1415926535897932384626433832795 and 3.14159265358979323846264338327950 are two different strings.
Practically, since TeX will have no new features as they only fix bugs now and the last bugfix release 3.14159265 was 7 years ago, I think we'll actually never get there.
Oh wow, I didn't even realize that was who wrote this article. One time I was debugging an insane USB issue and diving deep into the usb stack of the kernel (it turned out it was a hw bug, but that's another story) and out of desperation emailed the usb kernel mailing list for tips, and GKH responded to me.
Anyone who is deeply knowledgeable about USB automatically has serious cred in my book. That rabbit hole just about killed me.
Pain felt. Took me a month to find what turned out to be an obscure bug in an early USB 2 chip, while implementing it on a printer for Kodak as a proof of concept.
(I just added bigint support to a silly little interpreter project I'm working on. It took about fifteen minutes, four of which were looking up git commands, and the compiler told me what to change. Year 2021 and so it goes...)
Sometimes I explain things like this to my a friend of mine who is at least as smart as I am but doesn't computer and it's always so humbling.
To an intelligent outsider we (ye olde IT industry) look so goddamned silly.
I, for one, wish we could go back to using years for major version numbers. And as a stretch goal, trying to align release schedules with calendar years more closely. For example, long-term support versions could be even years. That gives the immediate benefit of knowing how old/how well-supported a given system is just from the year. I can't tell how many projects I've seen fall off and then look back...hey, the last version was from 2007. (not that being from 2007 is bad, it is just an indication that it's no longer being actively maintained and might be bitrotted).
When I worked on V8 our strategy was just to mirror Chromium's release cadence: every six weeks, the tip-of-tree became a dev branch, dev became beta, beta became stable, and stable became no longer supported. We did backmerge important bugfixes to beta and stable, but otherwise forgot about it. We never committed to long-term support of any version. That's not great for really important things like a kernel, IMHO.
I don't want to give up semver. When it's adhered to by dev teams (you can fuck right off, Spring 4.x where minor versions had major incompatibilities with previous version), it's a great contract to based your dependency management upon.
All of my major issues using semver is coworkers who just upgrade to "the latest version" in a library that explicitly states it's using semver, and then complain that it's backwards incompatible.
I definitely agree, I think the hard part would be educating end users though which version number goes where (i.e., human release number doesn't go in the Maven dependency).
And this strategy really benefits big institutions like Google, and harms smaller competitors. They are raising the barriers of entry. It is pretty clever.
Yeah, and in due fashion Chromium became "critical infrastructure" when SpaceX decided to use it as the basis of the Dragon capsule's UI. They pinned to a super-old version of Chromium that stopped getting updates 18 weeks after release. Which means it is absolutely chock full of bugs.
It's extremely silly to run a web browser on a spaceship UI, but I imagine that they have an entirely different set of bugs to prioritize compared to a desktop web browser release. Most security and privacy issues that browsers constantly try to patch up aren't really there on an isolated touch screen control panel. Unless they hooked it up to the internet, in which case may god help us all.
Hrmm.. But can you name any infrastructure as approximately as critical as a space rocket that uses some kind of rolling update release scenario instead? You raise a good point about the risk of pinning. Could it be that intelligent people also have valid concerns about the risks of _not_ pinning for such uses?
A quality shared with all software :) a threat model that includes bad actors hacking into spacecraft ui using known chromium vulnerabilities would have to include a dizzying array of more tangible physical threats we regularly discount
I don't know for sure if Tesla is also using Chromium for its in-car UI, but that's a much more tangible threat, because it is internet-enabled (and also not in orbit :-)).
If the software hasn't changed, then it was chock full of bugs when it was new, too. What has changed is that now you know what the bugs are. For a capsule UI, it seems to me that would be better than a new version with unknown bugs.
Sounds like my recent issue in Java with underlying library icu4j, which gives a nice start error ("Invalid version number: Version number may be negative or greater than 255"). Is an issue on quite a few versions of this lib.
What kind of idiot thought hard enough when doing this to actually create a custom error message instead of letting it go is slightly beyond my comprehension.
We're not a Java team, so it took us far too long to release this was the issue we were running into, and why it wasn't consistent between a few environments.
I'm not familiar with Linux version numbers, so apologies if this is a stupid question. How often do version numbers increment that any portion would overflow 8 bits? None of the software I've ever worked on would even come close to it.
Sorry if I wasn't clear - I didn't mean 8 bits for the whole number, just 8 bits for each part between decimal points. I can't imagine doing 256 iterations of something without deciding that you need to bump the next number up and start over at 0 or 1.
Linux strives to never break the API, and when it must does it in the most painless way possible. That doesn't mean they don't ever break the API, happens much more often than one would think to be honest. It's just the caution and planning around doing so usually makes it so few people ever even notice.
Yes but when people talk about kernel APIs not being stable they usually mean the APIs designed to be consumed by other kernel developers or kernel module authors.
Pffft, could just pull a Linus instead and rename all current releases by adding one in front of the major version and resetting the patch number. 4.4.256 becomes 14.4.0.
As a bonus, that would stop Linux's long-time lame lag behind Windows and MacOS, who were on 10 for years already and now 11.
Surely this is better than breaking userspace. GKH just invites another Linus' rant on the topic.
Is there a lot of pressure to keep these version number types as compact as possible?
I suppose it has to do with the use a tuple of 3 values and a desire to pack them efficiently into an API?
An API for fetching a version number doesn't need to be particularly efficient though. It needs to be friendly to humans and easy to reason about in code.
If your target audience is C, packing 3 values into one might even be the easiest to reason about, you get a single value that you can compare with the usual < and > etc. operators.
I don't understand your exact point, but the GNU C library ships with the strverscmp() and versionsort() functions, which do the same thing as `ls -v`.
The language already has an incredibly simple facility to compare version numbers (that GP mentions, but also there's macros), but you want to do it in a more complex way?
Humans can make errors in judgement or execution. When we look at affordances we look at filtering information to influence outcomes, and we try to eliminate mechanical errors like hitting the wrong button or transposing two activities.
Which is a long way of saying long numbers get more typos.
It’s all a tradeoff though. You just have to have all the competing concerns if you want to get a good answer.
That's fine and I generally agree with you, but "humans are bad at big numbers" doesn't seem like a good rationale for choosing a data type for a computer to use to represent a piece of information as part of an API that isn't allowed to change. Computers are fine with arbitrarily large numbers, and in particular, Linux capable platforms are absolutely great at 32 or 64 bit numbers depending on their architecture. Using 8 bit integers seems like it could have been premature optimization. If the original API had just used "int" without thinking about it too much, it would have had the same practical performance as using an 8-bit type, and would have worked up to at least 2 billion on any reasonable platform. Maybe the API needed a guaranteed fixed size across platforms, though, and the original designer thought more than 255 minor versions was crazy?
Solving the "large version numbers are bad for this project" problem is a human policy concern, and probably better done via education/documentation or an explicit warning in code (like a compiler warning or console message if the version number is more than 3 base-10 digits.)
I’m not familiar with the code. But my assumption is that it’s not that they chose to use an 8 bit integer for the y-version field. It’s that they chose to use a 24-bit number for the whole version. OxXXYYZZ - Eg 0x050801 for kernel version 5.8.1. That lets you compare kernel version A with kernel version B using a simple u32 cmp. They could have used 16 bits per version field - but that would have needed a 64 bit integer, which is much slower on some of the systems Linux used to run on back when that decision was made. In retrospect that was a bad choice, but I’m sure it seemed fine in the 90s.
The problem is that if they spill the minor version to 16 bits (xxyyyyzz) then kernel version 4.256.1 is “newer than” kernel 5.8.1 - because 0x04010001 > 0x00050801. And that’s a compatibility breaking change.
I love that the resistance to updates and the desire for stability has lead to lwn running a news item titled `Two new "experimental" stable kernels`. What irony.
And the rigid rule that daft old prescriptivits insist on seems to have come from some random writer in 1770 going "I think this sounds better in this instance".
May I direct you to Language Log, a blog of professional linguists and grammarians whose archives will be only too happy to disabuse you of this daft old prescriptivist nonsense?
Nope, it's less. You can use "less few" if a naked less bothers you. "Fewer" is not a real word - if it were, then we would also use "manyer" as its antonym. And before you go off saying I'm wrong, let me remind you that language evolves as its speakers will it to. You are speaking English, you can decide to change it however you want and nobody can claim you're wrong. Whether your change sticks or not is a different matter...
I believe they are all instances of induced demand [1]: If you allocate a large pool of a given resource, you tend to use it more liberally, and in the end the consumption rate is about the same regardless of the size of your pool.
It's interesting to note that apparently people prefer to reconsider some wasteful uses of the IP address pool rather than switching to IPv6.
That's the story of our societies. Waste the cheap stuff until it becomes too expensive.
They can opt out if they do the math and decide that is worth breaking with precedent over.that said, let’s not pretend the maintainers made this decision lightly. It’s a thorny situation and this is the most ideal solution that was put forward, precisely because the (long-term) stability of machines running these distributions is of such importance.
