Version 2.0? You mean an entirely new program, right?
this post was submitted on 28 Feb 2026
1038 points (99.0% liked)
Programmer Humor
30111 readers
444 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
slight disagree: proud version is actually when you become so disillusioned with your old code that you throw it all out and start again
It's more logical than Linux's version numbering system:
Does the major version number (4.x vs 5.x) mean anything?
No. The major version number is incremented when the number after the dot starts looking "too big." There is literally no other reason.
And «too big» for Linus is around 20.
See that's totally logical, but it makes more human sense than computer sense.
It's logical if Linus has some numbers autism
Hmm, guy who wrote his own kernel because he didn't like the ones that existed. I'm sure he's totally neurotypical. /s
idk for me it's easier to rember ex xdna was merged on 6.14 than 2.253
Shame-antic versioning
Well that explains why I’m on version
0.0.7899999999998765
7899999999998765
Even if a developer would make a commit every second, it would take 250 million years to reach version 0.0.7899999999998765
no it's more like Copy of New File (2)_final
They go up to version 0.0.8, 0.0.9, then they go to 0.0.91, 0.0.92, ... 0.0.99, 0.0.991, ...
Most of the mistakes they have to fix are incorrect version numbering.
I have seen people just add '9's to it, so to not upgrade the minor, so 2.6.997 gets 2.6.9997 and so on
Some people cannot math.
load more comments
(1 replies)
load more comments
(10 replies)
load more comments
(1 replies)
i thought there was gonna be some LGBTQI stuff here when i read "pride" versioning.
Under semantic versioning, you should really be ashamed of bumping the major number, since this means you went and broke backwards compatibility in some way.
You have done something, that it's worth breaking backwards compatibility over.
Yeah I just forgot how the old stuff worked
Except from 0.x.x to 1.0.0. That one means you’re committed to keeping the API/format stable. At least how I think about it.
Bump the first number when you update to a version that breaks compatibility.
Bump the second number when you make a change that people might want to revert back from
Bump the third number for bug fixes.
load more comments
(2 replies)
I recently realized: fuck it, just have the build date as the version: 2026.02.28.14 with the last number being the hour. I can immediately tell when something is on latest or not. You can get a little cheeky with the short year '26' but that's it. No reason to have some arbitrary numbers represent some strange philosophy behind them.
I use 2026-03-01-05 too but the -05 does not represent the hour but the number of version i release today. like if i make five commits today, they will be -01, -02, -03, ...
I used to work on a product with version numbers year.release - 2005.9 then 2005.10, though we only had about six releases a year
Tried it in the past but ultimately abandoned it, as then release numbers lost all added meaning. I can remember what happened in release 2.0.0 or (kinda) 3.5.0, but what the hell was release 2025.02.15? Why did it break this random function?
Can you immediately tell? Do you memorize the last day you released? Do you release daily? There's definitely some benefit to making the version equal to the date, but you lose all the other benefits of semver (categorizing the scope of the release being the big one). That's not a strange philosophy, it's just being a good api provider.
You're right. I'm looking at it through a very limited scope: nightly releases. I've been working with "latest" so long, I forgot actual versions exist.
load more comments
(6 replies)
minecraft being on 1.21.11 (i think)
with the current team of devs who's ethos seems to be to never touch the already well established gameplay features there will never be a minecraft 2.0
the entire philosophy of development for that game would need to change for that to happen
Actually, Minecraft 26 comes out this year. They dropped the "1." and bumped the sub-version from 21 to 26 to match the year. They've also changed the way the new second tier works to be related to the quarter-year.
26.1 is due next month.
So yeah, there'll never be a Minecraft 2.0. The versioning no longer allows for it.
(This doesn't rule out a game called "Minecraft II" with its own set of unrelated but identical version numbers. Minecraft II 36.1 drops in ten years. Maybe. But probably not.)
honestly good for them, this tells me they realised how useless the "1.x.x" format is since they do not plan on ever having it tick up to 2.x.x, and changed it to something that allows them to convey more meaningful information
load more comments
(6 replies)
If there ever is a "Minecraft 2.0," they would absolutely continue developing Minecraft 1.xx in parallel.
Honestly, props to them. They could make a huge amount of money by just moving over to a 2.0 and forcing a billion people around the world to buy the new version (and you know those people would buy it), but they aren't doing that.
Minecraft recently changed its versioning scheme so the next release will be Minecraft 26.
Officially and under the hood it's still 1.26, actually. At least on Bedrock.
load more comments
(1 replies)
Lowkey how I version number personal mini-projects and small things I roll out for my team.
I guess more like:
x.. "huge new feature, scope expansion, or cool shit."
.x. "small feature, or fixing a serious bug"
..x "testing something. Didn't work. Try again +1."
I'm not ashamed it didn't work. I swear!
I guess ..x. means NOTHING to you....... ;-)
view more: next ›