8 Bits Are Enough for a Version Number
kroah.com
kroah.com
3.1415926535 8979323846 2643383279 50
So not for a while
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.
P.S. on my screen your pi symbol π looks too much like n, I was confused for a moment.
>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.
Anyone who is deeply knowledgeable about USB automatically has serious cred in my book. That rabbit hole just about killed me.
Here's an AMA GKH did a while back if you want to get to know him better: https://www.reddit.com/r/linux/comments/2ny1lz/im_greg_kroah...
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Firefox_version_history isn’t compete, even if you click through to individual pages, but it would hugely surprise me if there were less than 256.
Any product older than 25 years would need only 10 releases/security updates per year to get there.
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.
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.
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.
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.
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.)
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.
Your reasoning is still holds though:
0x00050801 (5.8.1 8b for patch) < 0x04090100 (4.9.256 16b for patch)
Or maybe writing a version_cmp function or similar.
On a serious note, using fewer datatypes is super helpful for any kind of serialization.
This message is sponsored by your friendly neighborhood grammar nazi.
http://itre.cis.upenn.edu/~myl/languagelog/archives/003775.h...
The usual way to refer to this distinction is uncountable vs. countable nouns.
https://languagelog.ldc.upenn.edu/nll/index.php?s=less+fewer
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.
No silly overflow, MINOR will be clamped at 255.