Post

Proposing an extended SemVer - 🗿 Epoch Semantic Versioning to communicate better about versions. Thinking of adopting this to all my projects, and finally eliminating my lousy habit of forever zero-major practice 😜 What do you think? 👀 antfu.me/posts/epoch-...

antfu.meEpoch Semantic VersioningProposal for an extended Semantic Versioning called Epoch SemVer to provide more granular versioning information to users.

Florens Verschelde

@fvsch.com

So it's the same as semver-with-many-majors and semver-but-keep-the-major-as-zero-so-that-every-minor-can-be-breaking (already a common practice), but with gaps in the major version to jump to 100, 200, 300. My take: tiny marketing win at the cost of awkward gaps in the versioning scheme, meh.

9/1/25, 11:56 am0 reposts0 likes

Florens Verschelde

@fvsch.com

9 Jan 2025

As a user of many packages and libraries, this is also not a problem I have with libraries, and may perpetuate a problem I do have. In my experience, 10 breaking changes are not easier to deal with when spread as 7 majors instead of 1. The only thing that is easier: fewer breaking changes.

Florens Verschelde

@fvsch.com

9 Jan 2025

Progressive breaking changes have one upside: you can try upgrading major releases one by one. It's still a painful process. Downsides: - flip-flopping changes (v11 changed an API, v16 changed it again, v21 yet again…); - encourages maintainers to give low guidance for breaking changes.

Florens Verschelde

@fvsch.com

9 Jan 2025

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.