spicychickensauce
There are many v0 libraries in the elixir echo system, where at least officially, semantic versioning means nothing.
However, it seems to be very common to treat the x in v0.x.y as the major version, which allows for small but regular breaking changes. These projects are essentially doing 0.MAJOR.{MINOR + PATCH}.
Also, many v1 projects then avoid doing even minor braking changes, since that would mean they would have to go to v2, and they want to reserve v2 only for big, major changes. Or worse, they might even “sneak in” breaking changes without bumping the major version.
This is exactly the scenario described in Epoch Semantic Versioning. In that article, Anthony Fu makes a great case for why adapting Epoch Semantic Versioning would be a huge improvment for everyone.
Here are a couple of version numbers for some project, if they would start to follow epoch versioning:
| package | version |
|---|---|
| phoenix_live_view (would have been v20 before v1k) | 1_021.1.7 |
| floki | 38.0.0 |
| gettext | 26.2.0 |
| postgrex | 21.1.0 |
Also, some currently v2 projects like phoenix_pubsub might “still” be on v1_002, since maybe the breaking change that motivated going to v2 would not have felt like it would warrant bumping the epoch.
My main point is that I think epoch semantic versioning is much better at communicating intent, while at the same time keeping all the benefits of strictly following semantic versioning.
Plus, since it is fully compatible with normal sematic versioning, all the tools we have like hex and mix already handle it correctly.
Would you like to see libraries adapt Epoch Semantic Versioning?
- Yes
- No
- I don’t care
Where Next?
Trending in Polls
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
sanswork
Currently pretty much every maintainer has such a different idea of what constitutes a major/minor/patch change that I don’t really trust any version number to be insightful about the size of the change or difficulty updating to the new version until I’ve followed a library for a while and have seen several releases from the same person. As soon as you add a new standard for versioning someone will question if something really is a major enough breaking change or not or if they’ve been stuck on one epoch for too long or long enough and we’re back at the exact same situation as current.
spicychickensauce
Thanks for providing an explanation for the “I don’t care” voters.
I fully get that, that certainly wouldn’t be different if some libraries were to start using Epoch SemVer.
You always have to vet each library and author carefully to build enough trust to know how updates might impact you.
However, I think the intention of Epoch SemVer is exactly to make those decisions simpler for the author and more intentional.
As in: if it’s a breaking change you always bump the major version, no exceptions. (I understand that there are different definitions of “breaking”, but in general I think it’s still pretty clear what is meant by that).
And bumping the epoch is essentially just “marketing”, so you only bump that if you want to write a big announcement blog or if it just generally “feels” like a new major version.
Of course normal SemVer also follows the same “breaking change → major bump” rule, but in practice people are often reluctant to actually do it and then wait until they have a bunch of breaking changes such that a new major version is actually “justified”.
Could someone speak for the “No” voters and explain why you think this would be a bad idea?
DaAnalyst
A NO voter here.
My take is that a major version number should reflect the corresponding feature-set changes as opposed to breaking changes, i.e. it should be an indicator of the marketing intent and not a breaking change counter.
Your example with LV clearly shows why.
DaAnalyst
Also, my view is that it’d be better if a version was comprised of 4 numbers instead of 3:
<marketing/product version>.<breaking changes>.<feature add-on>.<fix>spicychickensauce
Wait, I don’t get that at all? That’s exactly the argument for Epoch SemVer?!! I also want 4 numbers. 4 numbers would clearly be the best, Epoch SemVer is a compromise solution because our world already works on 3 numbers only.
So we do actually want the same thing, but I guess you think the implementation in Epoch SemVer to achieve that is not a good way to get that?
DaAnalyst
Yes, but IMO the compromise in this case (the proposed “cure”) is worse than the proverbial poison. The first number should definitely be a marketing/product number.
Also, why not switch to 4 numbers? If it’s legit to suggest enforcing a new meaning for the 3 numbers then it should also be legit to suggest an extension to 4 numbers.
spicychickensauce
Ok got it.
I would absolutely also be behind actually allowing 4 numbers.
However, I think there is a much smaller chance of that happening.
The Epoch SemVer proposal can already be adopted by library authors today if they want, all tools already support it.
Also, just to make this clear, Epoch SemVer does not really “enforce a new meaning for the 3 numbers”.
The 3 numbers technically still mean the exact same thing as they do in SemVer. The only difference is that it allows jumping 1000 major versions at once. (Technically SemVer also doesn’t forbid jumping versions, so even that is compatible with SemVer)
mudasobwa
In the ideal world, populated by pink unicorns and fairies, I’d love to tweak a SemVer to be “FeaturePack.ImprovementsAndBugFixes” That implies we never make a breaking changes to our code (which is not so impossible, actually.)
Yes, Elixir would have been somewhat like
4.20at the time being. Technically, Erlang does somewhat very similar to that. I am pretty sure they might easily drop patches and have28.3now instead of28.0.2.So introducing the forth segment looks extremely obscure to me. What do we usually do as developers?
—
mix deps.update --all(hopefully reading the respective changelogs.)How the version being
2.3.4.5tells anyone more than2.18? I mean, seriously, it could not matter less, whether we use N-digit number system with a base M or M×N number system, or whatever.sodapopcan
We could always just use less(1)'s versioning strategy
mudasobwa
vthere looks as inconspicuous as a tarantula on a slice of angel food cake.Edit: I should have attributed this. The quote is stolen from Farewell My Lovely by Raymond Chandler.