spicychickensauce
Would you like to see Elixir libraries adapt Epoch Semantic Versioning? (poll)
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
Most Liked
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.
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>
BartOtten
Making my point. Both were breaking in their early existence.
If you have found the new better interface, I bet it is to be named distinctly.
Because a better interface automatically leads to a better name? When I switch the argument order, there is no need for a new name and it would be worse to give it a ‘forced’ new name while the ‘old’ one was perfectly describing the function in the shortest way.
Plant warning for obsoletion
Again: in new libs it is polution imho . Break early and take the penalty. Once you are ‘too big to fail’ there will be enough times you have to ‘polute’ the code base with functions obsoletion. Just as you can see in both examples you provided. Breaking-strategy when small, obsoleting when larger.
That’s all I gotta say. Back on topic: epoch semver!
Popular in Polls
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









