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
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.
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 😀
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.
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.
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.
Normally that's used as Major.Minor.Patch-PreRelease. I don't recommend adopting that approach as something other than PreRelease.
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
@@a_n_t_e__ If you cannot understand very simple meaning of 3 numbers separated by dots you probably should not be a software developer.
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.
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.
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.
As far as I understand it, yea you are right. BUT Anfu proposes this not because SemVer is bad or used incorrectly, but because of human error. I can understand v1.2.3 and v2.3.4 is just as big as a jump as 123.4.5 and 124.5.6 is. But the average human who does not involve themselves in tech but only wanna use it, maybe do not understand it. "The version have changed from v1 to v2 this will himpact me so much" vs "The version have changed from v123 to v124, it changes barely anything" one is an increase of 100% the other is 12.3% increase a difference of 8.13times.
If a person who does not understand that it basically is the same but can still see the number it maybe doesn't update. Lets use an example:
A gamer have a game it is on version 5, avery time a new version is out he updates until version 15 when he starts to update every other or every third version because HE haven't noticed any big changes in the game or performance. The higher the version is the less and less he updates it, because the version becomes higher the visible change in his eyes becomes less and less.
It is similar to how we humans often make a big deal of a babies first word, the first time they walked, their birthday etc. At a certain point we stop caring until certain milestones. Take birthdays as an example, we maybe celebrate every year until you are ten, then we maybe celebrate when you are 15/16 when you can get your first license, then at 18 because you are an adult now, then at 20/21 because you can buy alcohol, then at 40, then 50, then 60, then 70, 80 and in the 90s we celebrate every year again because each year is a milestone when the life expectancy is under 90.
What anfu proposes is that the epoch number should be the one you tell the gamer is important, the epoch number is that milestone.
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.
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
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.
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.
That's why we haven't seen version 4 of Winamp :)
to my mind, sounds like a solution for a problem that does not exist for 95% of developers.
This is a bad idea. SemVer explicitly exists as a machine-readable versioning system. Trying to make them "marketable" just invites people to make more cosmetic changes, which will inevitably cause people to create something that isn't compatible with SemVer.
If you want to include a marketing version, then label the update in the changelog or wherever you want to download it (e.g. 2.0.0 "Fancy Giraffe" or whatever). Your package manager won't care at all about it, but humans can still see it where it makes sense to see it (which isn't in the SemVer version).
It's not just machine readable - it needs to be readable by non-developer WordPress admins who are updating plugins automatically or manually based on the numbers, not on changelogs or commit messages.
Dumb take Theo
Nah, it's just lack of education & consistency
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?
@@gomesbruno201 It's just whether the API is stable. I don't see any problem why they dont just bump to 1.0 and increase major version once they need it. No one cares if a crate is at v24. But I do care about having to read changelogs vor 2/3 of my dependencies because it's not obvious whether I have to make changes or just update.
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
I always thought firefox being on version 135 is weird, but it actually makes total sense.
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
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
i like existing versioning format, if it does not work for you that does not mean it sucks.
You can say whatever you want, but React should have reached v1 years ago, and no one is going to tell me otherwise
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.
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.
Adding a code name for every epoch is super smart
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.
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.
Never really had a problem with this versioning system. Just people not understanding it FULLY
What I ❤is how Theo called the average person dumb then realised… it included himself 😂😂 Yep SemVer does that to us all
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.
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
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
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.
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.
We are fixing what shouldn’t be fixed. We should fix the “SemVer” not the number in the major.
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.
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
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.
Fireship could do a 30 second recap 😂 all this time to just *add a marketing version* before the rest of the semantic versioning
Just to mention the Laravel case, where community was complaining about new major versions being released too quickly :D
SemVer isn't the problem. The problem is people.
If you are going to make an "Epochic" change make it BIG!
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
@@reas0 You can have that in Zen too.
I've had my whole app break far too many times because of a patch version upgrade.
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.
12:34 epic George Carlin mentioned moment
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.
Human's don't suck, our communication does!
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.
I am in the one percent that a minor change breaks my code, İ write automation tests on hardware, almost every month there is a new fw update, in these "updates" sometimes some minor updates breaks our code and we nead to update it, and this change can be done dynamicly(it can be read from device and put it to variable) but we cant do that, because we want to know when this change happened, it didnt break other functionality because things that we can get from the devices are important to our tests
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.
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.
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 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?
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.
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 :)
Three numbers is already pushing it. This only further complicates things. The obvious solution is to just combine minor versions and patches. Both are supposed to be backwards compatible. It should be "..".
Semver is great for packages and libraries I think. For when you create your software (binary) though something like ENV.year.week.patch makes more sense to me (e.g. DEV.25.5.12 or PROD.25.5.1). So many projects also use some time based versioning which for the binaries I think make sense. For libraries/packages (classic) Semver makes sense to me. And it's kind of weird how a mayor version is so expectations driven and that that would kind of hold us back in just releasing something with breaking changes (even if we know it's a better way of doing things)
this video wasn't as controversial as I thought it would be 😂
i will let AI worry about breaking changes, i am vibe-coding now days. accept your reality.
Theo, the method that people should use should be dependent on how fast the codebase changes. Generally, 0.x.x is meant to be used until you reach a stable release, but I don't see that as being any more valid than reaching 10's of thousands of patches. The method I like is to use the date as the patch number, specifically with the international format. If you know the strftime() format specifiers then %F. If you need more than once per day releases, then I'd add _%T on to that. Once enough changes have accumulated, then bump minor. Once a breaking change occurs, bump major. Simple as that. Then the patch numbers are super easy to track, because it's literally the date of that patch, and major and minor pertain to public releases and API and feature changes.
So... nothing will change.
"Breaking changes are not the same as marketing events." Nice... 🧠🧠
She sematic on my versioning till I sucks
I like Apple or Ubuntu naming scheme. We should use this like a combination of an adjective verb and an animal or something
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
You bump the major version from 0 to 1 for the very first public release => problem solved
Keep in mind the huge and wide world of WordPress plugin updates, that use this system. And the many 'managed' hosts that update automatically or not based on the numbers.
Making the version more 'semantic' doesn't make it clearer for the small business owner about to break their site with a click.
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.
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.
End users have no idea what software versions even are, and they don't care. And developers understand semantic versions, they are fine.
The best versioning system has always been yyyy-mm-dd because software is never truly complete and looking at how frequently is maintained is what gives you confidence its maintained. you can commit to a specific time frame, its simple and nice, no real cognitive load either.
this video just lists a bunch of issues with versioning that are explicitly and simply addressed by semver and then proceeds to say semver is bad because people are “scared” of big numbers and refuse to use semver as it’s defined.
coming from mechanical engineering.... it can be more numbers, letters or a combination... whatever you want. what matters is the documentation/data behind it to crate an understanding for the users. it is rare mupitable versions are active at the same time, and if a change is 'big' enough its a whole new 'thing'.
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.
This seems more like a ...(let me phrase it so UA-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.
MY MAN ANTFU DID IT AGAIN ❤❤🎉🎉🎉❤🎉❤
After three years of working with Java and Javascript I am afraid to do a PATCH update for the dependencies...
correction: humans do not suck!
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.
A lot is stupid here - but it is not really SemVer itself.
That's how i use my versoning for a react native app, major for marketing, minor for native build ( major change in a way, since it breaks the api between the bundle and the native part ) patch for ota ( minor )
If you are not able to understand basic things like numbers and their meaning. You should NOT be an engineer!
And here's me just using v2024.02.10 (todays version, easy to find, and assumes a breaking change the more days that pass since you updated).
You can use a new package name for a new epoch.
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.
Which would you consider an "Epoch" of a abstract thing? 100 things or 1000 things?
One thousand === 1 Epoch? No?
It would be nice if TypeScript followed semantic versioning.
before even watching the video, i wanna say that i read four digit versions as {release}.{major}.{minor}.{patch} which i understand as some sort of indicator for an RPG beast of a particular species, with release number being its level, major being all stats compounded, and minor/patch derived out of what pokemon fans call IV and EV respectively, i think. species would be the project, of course. the changelog are the prompts after gaining experience, which you don't read if you're grinding, probably against the developer's wishes/with the understanding of the developer.
on a more serious note, i think an essential part of planning software projects should be deciding on a sensible naming scheme for releases meant for end users, and a lot of projects should not be exposing their puny little version numbers to the end user so shamelessly.
12:40 Theo perfectly describing me
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
Semver goodver
{MajorChangeBreakingBackwardsCompatibility}.{NewFeatureAdded}.{BugFix}
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)
so like Unity 6 does it, 6000.0.0 where I suppose it could look like 6001.0.0 when a breaking change happens
I love how all the exemples are purely dev stuff (sharp is clearly not for users. React native too, and the css stuff too)…