It's time to fix semantic versioning
ฝัง
- เผยแพร่เมื่อ 9 ก.พ. 2025
- Semantic versioning is kind of nonsensical, but it's the best we have. Or at least we had, because this new proposal is very interesting...
Thank you Infinite Red for sponsoring! Check them out at soydev.link/in...
SOURCE
antfu.me/posts...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
If something adopts this, you should always start at v192.168.0.1 for maximum confusion.
Heathen, it should be 127.0.0.1 obviously /s ;)
I’d be like, “is this an ip address or version number!”
@@ErrorINAOfficialyes changing version also proxies the application to another address. Duh!
🤣
But it only has 3 numbers
The problem is not that semver is bad. The problem is that one half of developers don't know how to use it and the other half don't know how to interpret it. Well, if people are stupid, let's do yet another stupid scheme. Genius!
if people still don’t understand it, then yes it’s bad
I think many developers understand, but the marketing thing fucks it all up
The issue with SemVer is that past v0 every breaking change requires a Major version bump, which many think means a "Major" change like going from SDL 1 to SDL 2 & many breaking changes aren't what many would consider "Major" unless there are a ton of breaking changes or the breaking change affects something at the core of the code base
That said if we're opening the box of rethinking SemVer while I think Epoch is better than current I really think we ought to go towards something like:
- Major.BreakingMinor.NonBreakingMinor.Patch
So that we can signal when there is in fact a breaking change, but it isn't something that would require massive changes for dependent code or necessarily even affect all users
A way to ham fist BreakingMinor into existing SemVer in a rather obvious way would be to multiply the BreakingMinor by say 100 or 1,000 such that 1.5.75.12 would translate into 1.575.12 or 1.5075.12 eventually enough BreakingMinors would warrant a new version to signal to folks who didn't update along with the BreakingMinors that they've likely got to make some "major" changes to their code base
If a tool made for communication between people isn't understood in both sides it means that the tool is broken.
@devnom9143 then don't break things? Add deprecation warnings, implement new features using new names, or semantics, and keep old functions, or rewrite them as skeleton aliases to the newer features. Then remove all of 'em on the next+1 major release.
This tries to solve a problem that SemVer never had, because it was never intended as a marketing tool. It is clearly and carefully defined by compatibility of API changes. Moreover, anybody who doesn't understand SemVer now won't understand epoch versioning either. It sounds more like XKCD 927 to me.
I knew which XKCD that was before even looking haha
This whole conversation is idiotic. If people cannot learn semver, then they won't learn anything different.
Agreed, if you have a relevant major for marketing, you can just name it, giving it an alias makes it marketable, not all majors need to be marketable tho
Wow you are really negative and hate humans and yourself
I don't see anything technically wrong with SemVer. People just attach too much to a number. If a lib constantly needs to do breaking changes then maybe it should stay in 0.X.X (unstable range) forever. A lot of tools that i use never never had and probably never will have a 2.X.X because they don't do breaking changes.
Also the versioning isnt for the marketing. If such a thing is necessary, the wrong people are choosing the technology.
like rust for example wiill never have breaking changes so they're stuck on 1.X.X
That's the whole point of the video. There is NO problem with subver, humans are the problem. So a minor adjustment to subver to account for the average human psyche.
You can think of it as an offset/buffer/pad so that the edge of a font isn't exactly on the edge of a monitor/window. Taking into account human limits.
The classic issue with SemVer is when a library bumps a patch version, and they change a default behavior. Technically, one could argue that it’s a patch bump, because the consumer doesn’t need to update their code in order to consume the new version. But in practice, the new behavior forces consumers to change their code. That’s where SemVer has issues establishing best practices (it doesn’t afaik).
Personally, a behavior change is reason for a major bump.
@federicomedinauy that's someone misusing subver then. That's not a patch, that's a major version number. Default behavior imo is part of the API and it is not a backwards compatible change as it requires modification to the code base. You've described someone with a fundamental misunderstanding of subver. The sort of person that makes people think subver is the problem.
Be like linus and change the major version when minor version becomes too difficult to count
I do an end-customer oriented software. EPIC.MAJOR.MINOR.PATCH are all single digit numbers and when the minor gets past 9. Because users love single digit numbers and the only thing they need to remember is "I use 1 dot 8 dot something...". In any other case, major is a breaking change which means that you will not be able to open the file created in a new version with older versions and epic is a message to a customer that a big part of the software is about to be overhaued user-wise. Patch is for when I screw up 😀
This is a terrible idea.
More frequent breaking changes means a lot more headaches for developers. It is hard to do major version bumps in larger codebases, each time a breaking change is introduced it is always risky. I'd much rather do 1 major version bump a year that contains 10 breaking changes, than 10 major version bumps a year. Anyone who suggest otherwise has no clue how real world software development works. Not everyone is coding a side project or works in a startup.
Semantic versioning isn't suppose to explain the size of the breaking change, it is a quick visual way to indicate to developers there are breaking changes. If you want to know the size of the breaking change, just go read the release notes or docs. It is not rocket science.
People who stay on 0.x.x major version should have moved over to 1.x.x when the software is considered stable. Version 0 means alpha or beta software, not ready for production use. If you want to introduce breaking changes post version 1.x.x just bump the major?! Why does anyone have to stay on version 0.x.x, surely it is just pure laziness.
Just use semantic version as it is suppose to, instead of not using it properly and complaining it doesn't work.
Edit: typo
Arguably, smaller major version bumps may lead to less update headache overall as each of the updates are smaller and less cumbersome to deal with. You know how awful it feels to jump between 7 major versions-and how it's a lot smoother to just move 1 major version at a time as they come out? What if we could break major versions down into smaller units-smaller units that would be easier to incrementally adopt? Not saying it will work, but it may be nicer to work with than you anticipate.
I do very much agree that v0 should be for alpha/beta packages and v1 is for when you're ready for public consumption.
@BellCubeThe real problem is that people are bad at robust API design which is why they constantly break their API to accommodate new features. If you look at OS API's you might have 3 or 4 versions of the same function but that's spread over literal decades. There's really no excuse to do major releases on a yearly basis or even more often than that when your project has a lot of users. it wastes thousands if not millions of man hours and is entirely preventable by more thoroughly designing an API upfront.
@pokefreak2112 I do agree, but I'm also not in the camp of PHP's mysql_escape_string() and mysqli_real_escape_string() being good design. I also don't believe that omniscient foresight is... common in the software world-especially not in the still-developing fields of software development and tooling. There's a balance somewhere.
I do think a lot of software development tends toward too many breaking changes, but breaking changes are a different cultural phenomenon than users thinking major versions aren't what they are. Maybe devs would start rethinking their breaking change frequency if they were encouraged to break them up? idk though-and I think these are different problems in any regard.
true, it depends on the software ofcourse, each case is different, but in a company, where i work, we do not want to release major version of app more frequently than 2 years, there are minor versions every few months.
p.s. existing versioning scheme is just fine.
No no no please Theo no we have only just settled on a standard please no let us not split into the wild west again
This is a backwards/SemVer compatible change, no need to panic.
I have seen a lot of people using a format like this:
Epoch.Major.Minor - Patch. I guess it is pretty similar, but I like how it seems more familiar. Having a version like 3.4.1-2 clearly shows that this is a minor fix from 3.4.1. And it works with most package managers.
THIS!!!!
It looks similar but doesn't work. The whole goal is to adhere to package managers and they look at the major/first number to see if a package has breaking changes or not. This versioning looks good but package managers will install major versions when doing a simple upgrade of your packages.
The problem is not semver, it's humans and lack of consistency. Nothing to see here folks...
A glove with fingers in the wrong places it's a flawed glove. Semver is a tool to communicate. From humans to humans and if it doesn't communicate well it's semver problem.
changing semver is probably easier than changing humans
I would never use N * Epoch + Major. I don't like that you're limited to N major versions per epoch and I wouldn't want to commit to a value for N at the start of my project. I like the idea of an epoch version, but squashing it into the major version number gives me bad vibes.
N = 1000 or N = 10,000 is not large enough?
@@sentinel9651 Imo the problem is that 100 may be to small and 1000 is just gonna end up looking ridiculous.
IMO, epochs should be YYMM, like 2410 and 2501, N should be 10000, months should be restricted to the first occurrence of an update within a quarter, and so marketing can just stick to using the quarter representation, 24Q4 and 25Q1 releases in the examples I gave, while omitting the rest of the major version for the general public.
In short, if you released 8 major upgrades between october 24 and december 24, you'd have your last version of december be something like 24100008.x.x, your users would only worry about the 24100008 part, and the general public would only care about the 2410 part, which you'd refer to as 24Q4 whenever you meant the latest major version (0008) in that quarter. You could go to 999 major versions in a quarter without any problems.
In semver the zero-major literally comunicates that the package is not ready for production, the fact we have many packages with 0 major is incredibly annoying, because for example npm threats it properly and ^0.28.0 is locked to 0.28.x and not 0.x.x as nonzero versions. But some people use it for 0.(major+minor).(patch) and other for 0.(major).(minor+patch). There is no benefit to doing this for production ready libs, you're just loosing number from your semver.
The only issue with semver is trying to use it for marketing, there is no reason to postpone breaking changes and bulk them into one bigger release. Just make upgrade path document describing what broken and ideally what to use instead, with that upgrade from 2 to 3 with bulked 20 breaking changes is identical to upgrade from 2 to 23.
You're argument about upgrading nextjs without any issues tells that either there wasn't any breaking change and they bumped major for marketing reasons or there was breaking change and you just wasn't using the feature that broke that release (the fact you are not using new features doesn't mean they didn't break old feature).
tldr; semver is fine, just use it for versioning and not marketing. Promote features not versions. It's totaly fine 5.32.0 being huge release.
as long as you actually use common sense, it actually works just fine and is actually quite intuitive.
The more decimal points in you are, the more minor the changes are. Just because some people have a weird attachment to the major version number doesn't mean the entire system is flawed
but it's never properly defined what "minor" actually means, that's the problem.
Like let's say you have a js lib that takes in a config object and they add a new option like configure({foo: 'bar'})
a lot of people would consider this a minor change because they only added a new feature and did not modify behavior for the old API
But if you happened to pass an object with the foo key in an older version it suddenly goes from being silently ignored to enabling some feature flag!
same thing for fixing a bug, if you relied on the "incorrect" output like getting a NaN back and they "fix" the code to return a 0 that's also a breaking change.
Well, it requires you to think which most people probably dont do. Ironically in this field.
@pokefreak2112 there is a specification document on the semver website that details all you need to know :)
@pokefreak2112 If client used non-public API, it's a client's problem. SemVer is about public-facing API. In case of a fix which breaks behavior, the best practice would be introducing a new API with altered behavior and going through deprecation cycle for an old one.
Agreed
If the problem is that humans interpret the version number logarithmically then we can just start to number it thereafter. For instance, if the change from version 5 to 6 is larger than the change from 1 to 2 then just make the change proportional, for instance v5->v10. Problem solved and backwards compatible.
Yes, I think just doubling the major version would be a good idea for marketing.
Dumb take Theo
It would be very weird if a project that wants to release versrion 1 (major release) to announce it as v100.0.0 ... I think people would be more confused why a just released app would alreay be v100. I am thinking about something that is being developed in private and waits for them to have their first major stable version of their app before releasing.
Bruh. I prefer X.X.X.X rather than 100X.X.X, lol. I hate this idea of having epoch being multiplier.
Even if there will be problems with 3 dots, I will continue using this style, noone uses my stuff anyway xD
This is pretty extreme in the rust ecosystem. It's normal that 2/3 of your dependencies are 0.x and it's very painful to just upgrade all packages with minor changes.
It's good that it's painful, you should not feel encouraged to depend on fragile software
@ They are just afraid of putting on "v1". The base64 crate is at 0.x. Like base64 could change some time?
@@_nikeee as far as I remember, version 1 depends on a lot more than just stable code, right?
Nah, it's just lack of education & consistency
You can say whatever you want, but React should have reached v1 years ago, and no one is going to tell me otherwise
13:05 Not exactly what was meant here, but loosely related: Our team had to decide whether to patch a bug or not because it was funny. No one complained about the bug, it was a visual issue in text rendering, but people had fun with it. Ultimately, we took it out, though we still debated undoing the patch for weeks lol
Debian (and hence by inheritance any other OS using the dpkg format) addressed this with EPOCH:ver.ver.ver-customstring what feels like a very, very long time ago. Most packages don't need to have an epoch but adding it to the versioning standard helped them get out of some corners they'd painted themselves into.
i like the way mojang does it with minecraft (java edition), they use semantic versioning for major releases/bug patches
for example, 1.21 was a major update and 1.21.1 was a bug fix.
but for development builds they use {last two numbers of year}w{week no}{a, b, c, etc.}. for example, 25w06a was a development build that was the first one released in the 6th week of 2025
They changed the way it works recently and it makes no sense anymore.
Edit* For example 1.21.2 was a small update, 1.21.3 was a bug fix update.
@@america1754 oh yea i forgot they did that
BRO WHAT! Mojang has never respected SEMVER nor been consistent on how they label versions!
They will literally release a x.x.x release and it breaks existing things.
The first number is supposed to be the major, the second the minor, and the third is patches.
Dude please just don't. This crap has made the dev community mad since forever, don't you dare praise Mojang an inch for their horrific versioning.
@@america1754that still makes sense. It’s a small update and not a new major content update
@@PanoptesDreams tbh semver is never made sense in any games lol.
The thing epoch semantic versioning misses is the ability to increment the marketing version while guaranteeing backward compatibility with the previous version. Like if you've introduced some very significant new features and maybe improved performance to make entire new use cases possible.
From memory I think Symfony generally does a X.0.0 major release with pretty much only breaking changes and not new features, and then often introduces lots of new features in the X.1.0 release, maybe on the same day? The new features having been made easier to develop by the breaking changes.
Is that much of a problem though? Huge marketing pushes that are totally backwards compatible don't seem that common empirically, and if you do have one like that you can just advertise that in the marketing itself. By definition marketing pushes draw attention, so users are almost guaranteed to see it, and then they know they can update safely.
I think the actual problem you're getting at is just the underlying subjectivity of semantic versioning. I wouldn't necessarily see your example as something worthy of incrementing the epoch, but obviously you do. We both understand, however, that the version numbers are gesturing at importance, and an epoch number gives more resolution into the levels of importance.
What I ❤is how Theo called the average person dumb then realised… it included himself 😂😂 Yep SemVer does that to us all
Sem versioning is not bad, people need to understand it’s use, for me the rule is semver for libraries and apis, custom version for client facing. For business loves marketing new versions even if the change is ui colours. But for api and library that other developers depend on semver is perfect and makes sense. Sometimes we slap on a build #number to our m.m.p or a label when required.
So... people don't correctly interpret SemVer, so lets create another SemVer with an additional rule and that won't confuse people? He already notes that people should rarely use epoch, so what happens when you reach the 100 threshold naturally by incrementing the major? This is just an extension to SemVer that if adopted like SemVer, would run into the same "now its for marketing" issue. Not to mention that there are already packages, as you point out, that are far beyond the v100, which will just create more confusion.
The problem isn't SemVer or its spec, the problem is people incorrectly using it, and that won't change with changing to a different spec.
If you want to name a major release to indicate its marketing, then just do that. Why does that need to increase the version by 100 (or 1000)?
This really feels like the guy knew he was abusing the v0 and then decided to make it everyone else's problem.
I can second that. I bumped into Jamon before theo started streaming and he is by far and away one of my favorite people in the industry. Everything Theo said about infinite red and jamon is an understatement.
❤ Nice to hear from you @DaxSudo! You’re too kind
I've seen some packages do something similar already. Some Angular tooling uses a version number like 0.1901.6 to match Angular-CLI 19.1.6.
12:11 I (and many others) had that issue with Java 9, where they introduced the module system. Everyone was staying on java 8 for a very long time, because they were scared that the module system would screw things up. You don't even have to use the java module system, especially as an end-user (it's more useful for writing libraries). Java automatically creates a no-name module for you that basically behaves like how java 8 behaved.
I really feel sorry for anybody who implements this early if this doesn't take off.
Yeah there’s no going back 😅
it will never take off
I've had my whole app break far too many times because of a patch version upgrade.
Never really had a problem with this versioning system. Just people not understanding it FULLY
I think this is a pretty reasonable approach. It avoids creating a new standard and allows the version number to communicate more than it does currently.
Is that Arc? Thought you changed to Zen? Or is it a weird Zen theme
probably old video
@@rtrampoxtrue. Maybe someone who was on the stream could tell when it was made or something
It's Zen. Very customizable, it's just Firefox.
he has the tabs on the left so it's arc
It feels like creating a new problem to solve previous problem and it takes too much time to read new version name.
I think if you want to introduce new Epoch for ground-breaking api, it's better to introduce new package name instead like [packagename]2.
We are fixing what shouldn’t be fixed. We should fix the “SemVer” not the number in the major.
Arthur Mensch, CEO Mistral AI, recently said that they use the "Linux style" naming for their model. Seems appropriate in my opinion. It was during "Underscore" (a french tallkshow about tech) on the Feb. 6 for the curious one
This would solve SemVer problems:
{ProductRelease}.{Breaking Change}.{MinorChange}.{Patch}
or "RBMP" for short.
The first one would help all API consumers to understand the real product version. The last three are the same as SemVer.
I watched the video for 8 minutes and at some point I thought, "Wait, so he's just suggesting adding one number at the beginning for the marketing version?" I rewound it to the middle and yes, he really does. Theo, give me back 8 minutes of my life. It could be explained in one paragraph
Hey Theo, I just tried Uploadthing and I'm very happy with it. The only gripe I have with it, which feels ridiculous, it that in the "Files" tab, I can't delete multiple files at once. Even though there is a checkbox next to each file row, after selecting a bunch of files, there is no control to run an operation on these files I selected. I had to manually delete dozens of test files one by one, it was slow and frustrating AF.
Just to mention the Laravel case, where community was complaining about new major versions being released too quickly :D
I agree with the *1000 idea over *100
this way anyone can CLEARLY signal that they are switching to Epoch SemVer which could help with a signal to the broader ecosystem that people are preferring Epoch over OG SemVer.
People might end up naturally seperating the EPOCH number in marketing naturally then.
Seeing v1002.3.4 will more naturally translate to most humans as Epoch 1: Major 2: Minor 3: Patch 4
A change like this needs to be super clear and obvious to everyone.
But seeing v102.3.4 looks to much just like Major 102: Minor 3: Patch 4 so the general "average" and less than "average" person can mistake it for a project that has gone through versions 1-99 Major and think that the project is very "mature" and "production-ready" whatever that means.
She sematic on my versioning till I sucks
This seems more like a ...(let me phrase it so TH-cam doesn't remove my comment)... manhood comparison competition. First time I noticed this, was when Firefox, Safari, IE and Chrome all uses small increments in their browser version, and then Chrome suddenly decided to start using major versioning for each update. Everyone freaked out and thought Chrome was making weekly massive improvements. Chrome was suddenly at version 20.x.x whereas Firefox/Mozilla with years being on the market, was still at version 2.x.x. Solution? Copy Chromes versioning.
I see how most patch notes use the following format:
- New Features
- Changed Features
- Fixes
In the future, couldn't we change to an EPOCH.UPDATE/ADDED.CHANGED.FIXED.DEPRECATED format, where EPOCH is a generation, UPDATE is the release, ADDED is the number of new features, CHANGED is the number of breaking changes, FIXED is the number of fixed changes - but these three would be counted relative to the last epoch.
So for v2.1/3.0.4.1 ...
- This is update 1 of the 2G epoch
- There were 3 new features/functions added since 1.0
- There were 0 breaking feature/function changes since 1.0
- There were 4 bug tickets fixed since 1.0 (that shouldn't cause a regression)
- There was 1 feature/function deprecation since 1.0 (that might break by the next gen/epoch)
Commit messages could detail changes along the same lines with similar terminology, and the change logs and relative versioning could be mostly auto-generated using the commits and the version history. Does this sound reasonable, or is it too confusing/convoluted?
In my company, the "patch" version or just submissions of the current set of changes to be built in the larger project, usually there's a submission every week for the main branch. If you have extra numbers that come after, those are added fixes on branches of the orignal submissions…
The minor version, are large releases of the last major release we've made with stuff cherry-picked from the main branch, so we're usually adding smaller features if needed, but generally it will be fixes and clean ups.
The major version is when we put all our new features for the current cycle and we have 3 such releases a year.
If the problem is that package managers use the version to check for compatibility and humans want the version to have a marketing value, seperate them.
Add the option to supply an arbitrary number or codename to a package manager to display as the version and let the package managers use the actual SemVer for compatibility checking. If no "display version" is supplied, default to the SemVer version, let it be 0 or just don't display the version to the endusers.
I love how all the exemples are purely dev stuff (sharp is clearly not for users. React native too, and the css stuff too)…
Interesting problem, we circumvent it by introducing a product version which relates to documentation and UI stuff only and the technical version below is not related, hence marketing can do whatever they want and the devs can do what they need to do.
Ahh, George Carlin:
"Think of how stupid the average person is, and realize half of them are stupider than that"
Also, the iPhone 4 (and 4c) were nightmare launches. You could swipe to scroll the visual page out of sync with the touchable button areas (ie: button looks like it's at the bottom, but the touchable part of the screen is 80px above). Also, you couldn't do file uploads. Not via the file reader api; not via the input element. It needed an iOS ... I think it was an 8.1 ... update, for web to actually work again.
12:34 epic George Carlin mentioned moment
Human's don't suck, our communication does!
i like existing versioning format, if it does not work for you that does not mean it sucks.
Average doesn't mean that half the people are below average and half are above average. I see this mistake time and time again. For example, if you have 5 people with an IQ of 1 and 10 people with an IQ of 100, the average is ((10*100)+(5*1))/11. This means that 1 person is still below average, and 10 people are above average. What you're referring to is the median.
Unless of course he was referring to median and not mean (which is what is usually interchanged with the word average)
Fireship could do a 30 second recap 😂 all this time to just *add a marketing version* before the rest of the semantic versioning
I use Major.Minor.Build so there is a clear progression and clear emphasis.
Build simply increments forever while the others communicate actual changes in features and whatnot. Small features go in the Minor and large features go into Major. And yes, the number in the front is important if you are being honest about the work. The solution in the article seems like it change nothing.
I do like the date release versions too. They not only give context to scope but to time - if a user hasnt updated their version in two years, they would know.
It's not time to fix semantic versioning, it works great when people actually use it correctly. The worst thing is having people decide to use their own system for versioning. Just use the standard for good reason, consistency.
If you are going to make an "Epochic" change make it BIG!
Biggest problem I see is that major version is not "automatic", you have to manually do that and handle anything that breaks.
Now do that to everything else and you'll have a LOT of project full of vulnerabilities because devs are too lazy or too "it still works" because they wont be upgrading majors.
Regarding the nextjs v12 to 13 upgrade, should the version have been bumped from v10012.x.x to v20012.x.x to indicate “its fully backwards compatible, but we added the new app router functionality”?
"Breaking changes are not the same as marketing events." Nice... 🧠🧠
semver almost has the right idea but it's just too vague. I think the release types should be defined like this:
- patch: performance improvements with no change in behavior, any cosmetic changes or changes to non-code things like docs
- breaking: anything where given an input the new program produces a different output than the previous version. So Bug fixes and additions to the API fall under this
- major: complete API overhaul
under semver people interpret even the strictest patch releases as allowing observable changes to the input/output of the program, that's a major issue.
honestly that woul be much better, that's semver, but fixed
Sounds good, what counts as a 'complete API overhaul'?
It's as easy as:
Major: Changes that remove/change API
Minor: Changes that add API
Patch: Cosmetic changes that dont add/remove/change API
@@RomanAvdeevX but adding API can break a lot too, at least in js.
like if you add an extra optional parameter to a function and I was calling that function like f(...args) one of my args will suddenly go from being silently ignored to becoming a parameter that changes how the function runs. Or if I was accessing an object entry by index it breaks if you add a new field. So at the very least it should be defined as "only add new exports to the end of your module, do not change anything about existing code whatsoever". And even that can be questionable if the consumer happens to do dynamic import shenanigans.
@pokefreak2112 Why are you giving me an example of changing the API? Adding an API means adding new functionality, like adding new functions. Pretty much any backwards-compatible change
You can upgrade to 4 numbers if you don't reset the minor verion : 1.12.3.4 to 2.13.0.0
Then being compatible with semver is just omitting the epoc.
Except that would break the machine readable expectations by introducing breaking changes in what technically is a minor bump, which was supposed to be backwards compatible. Tooling such as NPM depend on this assumption to handle version range pinning correctly.
SemVer isn't the problem. The problem is people.
IMO: Most libraries don't really seem to use the "breaking changes" aspect of semver seriously anyway so we might just as well move to an incrementing number that says nothing but "newer" or alternatively the year.release-number approach like 2025.1 -> 2025.2 -> 2025.3 that some tools seem to have adopted somewhat recently
Explicitly not using something that resembles semver also means no expectations :)
{MajorChangeBreakingBackwardsCompatibility}.{NewFeatureAdded}.{BugFix}
Symfony's own interpretation of semver was the first time I realized it is absolutely terrible at conveying significance.
Every x.4 and (x+1).0 are essentially identical releases except x.4 is the LTS that will get bug/security fixes for a while but (x+1).0 removes a bunch of deprecated stuff so it's technically a major version. In practice there is no reason to ever install an x.0 version of Symfony, its only purpose is consistency.
I like Apple or Ubuntu naming scheme. We should use this like a combination of an adjective verb and an animal or something
End users have no idea what software versions even are, and they don't care. And developers understand semantic versions, they are fine.
I don't think this will help on its own. Whenever there is going to be a breaking change, you should first make the old behavior deprecated and keep it around for a couple of months, so users can shift to the new behaviour in their own time while staying on the newest version.
I do agree that I see versioning as a "how much has changed" as well, where a major version is basically a fundamental change in how the product works. I don't think Epoch SemVer would change that though.
You bump the major version from 0 to 1 for the very first public release => problem solved
Idk about you, but I always don't like pointless numbers, they always lack of context, so because of that I write all my code with versions like 2025.02.10
To me it's way more useful, because if I ever have to make a breaking change I would have like package version restriction, e.g. >=2023.11.19,
But what if you have to push a zero day fix
@@jordank195 Bump the day. They are meant to communicate dates to human eyes, but to the computer they are just numbers going up. If you want to check exactly when different things were deployed you will have logs or commits with timestamps in them to tell you that.
We version database table versions like this. I might author a new version of a table on one day and deploy it a few days later, so the date itself doesn't tell me exactly when it was requester or when it went live, but it does give me a rough picture of when it was made.
Great! The industry finally agreed on a standard & some confused JS devs come around and demand breaking changes.
Btw. Stop using semver for marketing you loons
After three years of working with Java and Javascript I am afraid to do a PATCH update for the dependencies...
If you are not able to understand basic things like numbers and their meaning. You should NOT be an engineer!
8:00 I feel like that's a mentality pitfall that Devs are being pushed to by their user base which should be ignored ultimately, since as you said your putting off releasing good changes because users are going "meh it's small I don't care". Them thinking that isn't your problem, it's their problem and responsibility to decide if they update or hold off and by proxy also deciding if they read the change-logs to make their decision. So In response to your question at the end of caring too much, I think yes your caring so much about what the consumer thinks that your preventing if not hurting your own progression via your efforts to try and appease everyone.
Part of why I think this mentality has come along is because of the fact that a few bad eggs made major version changes be the only things that had good or noticeable changes while their minors were nothing if not used for when the patches/bug-fixes were big enough for it to be an minor version update. Conversely users probably didn't update as long as what they wanted worked.
This proposal for Epoch versioning to me sounds honestly horrible due to the fact that humans are dumb as you said, which I can see meaning in the case of where I think of someone relatively middle ground would look at it and be confused by the big length of the versioning or mistake it for something else like IP address.
I mumble around on an HTML game making forum (mainly people using Twine) where most use X.X versioning with Semantic Versioning rarely used as people don't realize about it even existing. As a result consumers have taken 1.0 to mean the first version of the game is complete even though upon inspection of the change-log it comes clear it's 0.1.0 if it was Semantic as it's the first publicly released version and in an alpha state. However Devs that done the 1.0 for an alpha have quickly rectified it once the mistake has been pointed out to them so they switch it to 0.1.
Consumers themselves on that forum have gotten confused about even Semantic Versioning I've found so much so that while the change-logs have had Semantic Versioning previously at some-point it switched to the simple X.X with an alphabetical letter at the end for the purpose of indicating patches as they found that to be simpler and easier to understand what is going on. Part of this is that these HTML games rarely need patch versions so the alphabetical letters rarely get to E before an minor version update occurs but also for the Devs on the forum they have decided that 1.0 is final release usually where the game is content filled and then any versions after that is going beyond their original vision or patching problems if not UI overhauls.
If Epoch was attempted to be applied for forced for all the game threads on the forum I can guarantee chaos will unfold with confusion along with an overall rejection in part due to the sudden change but also how it wouldn't make sense to most since it would probably also make most Devs there feel like the work they've done to be miniaturized. (Since 0.5 would then become 0.0.5.0 in their eyes)
I'm not going to just complain/counter point without putting forward my own proposal however since I have taken a bunch from an specific instance. What I suggest instead is that how Devs present their versions should be changed since currently we have Alpha and Beta for indicating how complete an version is or it's stability. Why not have this for how we describe the Semantic versioning publicly while keeping Semantic Versioning in the change-log text?
For example of where you showed how you presented v7 and compared it to v6, you instead said "We are now in Version Gold (v7) of our development and we now consider Version Foxtrot (v6) now to be fully surpassed by it. However those of you whom have been updating regularly will see little in the way of changes as you have been on updates building up to Version Gold, identifiable via Semantic Versioning, if you wish to find out more about Semantic Versioning click here."
With that I feel that you simplify it for those whom don't know nor care for Semantic Versioning while also allowing those whom don't know but wish to inform themselves to find out and be made curious due to it's side mention. There is an problem with what I suggested of where you end up using up all 26 letters of the alphabet in the case where you release 26 market versions, however I personally feel that before you reach that you'll have hit something that results in you re-building your program from the ground up again so you make the name of it go from UploadThing to UploadThing 2.
One final thing I'll put forward as being someone new to yourself and the channel (I've watched barely an handful of videos recently) is that you appear to hold antfu to such a high regard you don't seem to even consider to analyze and give criticism on what they are saying. To quote what you said at the beginning ".....that if we disagree I'm probably wrong...." makes me further thing of this since it sounds like you now don't bother to argue about something they've said unless you KNOW that your in the right about it. This can be dangerous since if all antfu is getting is praise and no criticism then they could suggest something which anyone whom doesn't know them will have multiple problems with while those whom know him will be close to an `Yes Man` for antfu. My final reasoning/point for this belief I have is that you spend the video not only reading his post but you explain only the good points of it, you don't mention or give the indication that you've thought about how something could be bad or wrong with it which I feel you should have had an moment of when you said about the human race is dumb. Smart people can make mistakes and even the Smartest of People can make the simplest of mistakes like naming themselves in a forum as Doctor 0 and get mistaken as Doctor O by some when they could instead have it be Doctor Ø so they get referred to correctly when spoken to. (Fallout: New Vegas Reference)
Anyway I hope I've made myself clear as I've ended up writing this I believe from an Autism spurt of sorts.
Does this sound stupid? Specify the versioning scheme in the version string and refer to a centralized online database of versioning schemes (something like spdx) ?
If SemVer is the IPv4 of software. Then E.SemVer shall be the IPv6
i will let AI worry about breaking changes, i am vibe-coding now days. accept your reality.
stop
It sounds like you have an issue with Romantic Versioning and not Semantic Versioning.
why can't there just be an optional code name field in the project settings?
I currently favor using SemVer only for developers facing things and introducing another number for marketing. This epoch thing is mixing these again. Not mixing seems better to me. The extreme would be to create a new package with a v2 suffix.
Why not just merge patch into minor? What's wrong with `epoch.major.minor`?
Bug fixes, new features and (breaking) api changes would go into minor releases, behind feature flags.
Finished features and deprecations would go into major releases.
Epoch releases would be reserved for special occasions, where certain feature flags would be promoted (become the new default) and deprecated apis would be removed.
It would be nice if TypeScript followed semantic versioning.
So... nothing will change.
Which would you consider an "Epoch" of a abstract thing? 100 things or 1000 things?
One thousand === 1 Epoch? No?
While your example about NextJS versions not being indicative of features, Vercel literally market it that way. I don't think it's cool to label people stupid when software like this has been marketed as new major versions releasing containing a bunch of new features. Yes there may be other ways of thinking about it, but perhaps some of the blame should be pointed at how businesses market major version changes rather than assuming people are just dumb?
12:50 if nextjs changes were backward compatible then they should not bump major, they done it for marketing - bad example
I think this is a really bad take. What you really need is {Year.Month.Day.Hour.Minute.Second.Epoch.Major.Minor.Patch.OneLineChanges.CommentChanges.ConfigChanges.OneLineConfigChanges}
I think with that one we would actually be able to measure the right version of a project and when actual breaking changes are introduced.
18:51 don't you really think that they really have different epochs in AWS, wven though they are in "Minor" 100+?
I think your assertion that people are dumb is bad. I think people have a lot of things to deal with. Often in pretty much all "work place" software I've encountered, be in government, public or private, your code base ends up large and sprawling, importantly, with a large number of libraries attached.
You can't always look at and investigate every single library you use, and be familiar with it, at the release cadance that every library manages to maintain. Even with a small project and just 10 libraries that each managed a release a month (slower than Upload Thing) you could easily end up with several a week. That's a lot of stopping, tracking down patch notes, figuring out if you care.
People aren't bad. People are overwhelmed.
correction: humans do not suck!
I guess it would be a bit like hotel room numbers. 100-120 on the first floor, 200-220 on the second floor et cetera. Even though there's no 121 or 221.
this video wasn't as controversial as I thought it would be 😂
typescript version?
I'm not a big fan of skipping number you can go from version 112 to version 200. It just feels wrong.
A lot is stupid here - but it is not really SemVer itself.
so like Unity 6 does it, 6000.0.0 where I suppose it could look like 6001.0.0 when a breaking change happens
Years ago, I thought about version numbering (and I also agree that the current 'standard' is really broken), and here is what I decided to do, and still do because I haven't found anything better: date +%y.%j
Which yields (at the time of posting this comment): 25.040. Specifically, this gives you the year (25) and the Julian day (040). If you build daily, you are guaranteed a unique version number. If you need to release more often, you can incorporate the time.
But that misses the best thing about semver? Differentiating between breaking and non breaking changes