Post

Big fan 🙂 I've been using the other mentioned RomVer for a while, but too many people wrongly assume it's SemVer as it looks the same

Why not 4 numbers? Using this 99 majors per epoch seems to be begging for issues. Feels like storing years with 2 digits. The assumption of why would anyone need more than X of anything seems to always cause problems.

fits in nicely with semverflation, too 😅 www.zachleat.com/web/semverfl...

I used stardates for some Android apps. My idea of “stardates” is the number of days since 00:00 01-Jan-1970 UTC, to one decimal place. E.g. the stardate right now is 20096.2. What!? I missed 20000.0, just about a minute and a half ago!?

I wish we could just go EPOCH.MAJOR.MINOR.PATCH, though ideally we'd just have EPOCH.MAJOR.MINOR Not possible unfortunately

I don’t like it either, it doesn’t look elegant. But I have to accept it’s logical better than 0.x, under the requirements of being compatible with SemVer.

Your note about breaking changes, bugs, and people dependent on them reminded me of xkcd.com/1172/

The big jumps in major versions would take some getting used to, but ultimately, it's intent is to convey as much relevant information as possible. I also have a problem moving out of version 0 with my code for similar reasons, but I could see the grand leaps in major being somewhat confusing

It could work if major versions did not end up as part of the product name. It's easier to search for Nuxt 3 docs than for Nuxt 300 which is in the same place as 301, 302... That's why i like when groundbreaking changes are published as a new package. Nuxt3 1.0.0

Yeah it’s a common misconception! Versioning is for humans *and* computers, and semver has a fair number of concessions for both sides to get their work done. Us poor humans need to understand the spec the same as the computers do, which takes reading it. Humans prefer to complain about it instead 🤣

How do you handle this commit? - fix github action ... (x commits later) - F**** U GITHUB ACTION

GET BACK TO WORK!!!

Love this, thanks for sharing these thoughts Anthony.

I can tell you several horror stories of teams playing games with their version numbers and painting themselves into very painful corners. It is amazing how "clever" some devs can be.

> major and minor updates are interpreted *per project* 💯 Totally! Also, when using open-source projects, users are technically required to review every single change, as there are no warranties. In reality, people tend to trust maintainers as well as versioning, which is why it's still important.

I don't feel like the rationale in the article makes sense, this feels like a weird way to add complexity to an already working, simple, understandable "standard"

I’d love to have 4 numbers versioning. But as I mentioned in the post, it doesn’t work with npm’s ecosystem as it assumes SemVer every where. This is my workaround to that :P

I lean the other way. I think that we should have breaking changes and non-breaking changes. v12.456 for example. Note that this can be parsed into a real number which is a lot friendlier for things like Prometheus… plus the majority of devs I work with don’t understand semver anyway.

the whole idea of SemVer is just so not enough... and trying to "improve" it by adding another numeric section seems silly. the heck am I talking about? here, take a look: m.youtube.com/watch?v=oyLB...

I like the compatibility approach. One thing I don't like is until you finish one epoch there's no way of telling you're using this scheme, so I'd say ESV should start at 101.0.0

You could use dist-tags for epoch numbers. But in dist tags I guess codenames would work better.

I like how it can be adapted to the current syntax 😄

But I feel it's a cultural thing, rooted in fear ("I don't want to make it sound like a big thing for tech reasons") The current status quo is still not ideal 😄

Nice write up! I definitely wouldn't mind seeing you migrate your packages to this system. If I can comment on one thing: I think it will be easier to convince people to bump major versions more often rather than to adopt an extra "invisible" number. As you wrote, it's about human perception.

It looks like we have a lot of the same thoughts about versioning 😁 xavd.id/blog/post/ve... Yours is an interesting approach, I'll be curious to hear how your users like it!

I really like the idea! But I just came across a side effect: `peerDependencies`. For example, I think UnoCSS used to be "unocss: ">= 0.31.13 < 1" and now it should be "unocss: ">= 0.31.13 < 100" I think is an elegant solution the use of 100s for "major" versions. It is compatible! 🤘

But to be clear I for sure see this as “semver compliant” technically which is great because back compat is critical. We don’t use http because it was the best of the best design after all lol.

major - intentional breaking change minor - unintentional breaking change (includes bugfixes) I think this is the most important distinction for users, is SemVer compliant, and doesn't require an explanation for users to upgrade versions intuitively

i think your some sort of maga douche looking for fools to follow you

I think it makes sense for a mature-ish project when it can foresee minor breaking changes to happen often, and there's still value with v0 if that's uncertain, eg new projects. If not often, v1 still seems valuable to prevent number fatigue. So personally I wouldn't blanket adopt epoch semver 😅

Great post! Loved that you pointed out logarithmic thinking- something I’ve intuitively felt but not seen expressed 🙂

VueUse v100.0.0 is coming 😎

It sounds like you're just pushing the problem down the road by adding another layer.

I'll take one; boy, the wife will be surprised.

Brilliant strategy! With Epoch SemVer, spotlight game-changing transformations. Maintain clarity, ensure compatibility, and keep it user-friendly—all while staying in charge.

I'd rather see: 1. Normalize code mods. - This should be much more common; perhaps AI can make these easier to produce. - Tools auto apply Code Mods between your old and new versions. 2. Add a breaking indicator on the version. - Don't rely on Major/Minor changing to indicate breaking changes.

Of course maintainers who release many majors don’t HAVE to fall into these traps. But being able to release breaking changes often and in small increments allows hiding the extent of the practical instability of the software. I treat projects releasing 2+ majors a year as a red flag.

IMO this happens often in order to highlight the value proposition of updating in the face of breaking changes. If you just break stuff and don't offer something compelling in return, nobody updates.

Yeah, the temptation to use major versions as marketing events is (often) very high.

I keep thinking that `EPOCH * 10` could get the scheme more widely adopted. Given that any multiple of 10 would still have a big psychological effect no matter how this is defined, maybe it is fine to go with 10 instead of 100?

When a dependency with "versionStyle: breakingMinor" is installed, a squiggle range (e.g. ~1.2.3) would be used.