LOL, I have yet to look up the reference but ya, the v is unfortunate. I may be misremembering, and I’m not even sure this is an official repo for less, but my memory tells there was a non-github repo where the versions were simplly 1, 2, 3, etc.
sodapopcan
0
DaAnalyst
I pretty much never do this.
Regardless of the changelogs, I tend to lock versions of the framework libraries (LiveView, AlpineJS, ..) down to their maintenance/patch number. It’s been proven essential for avoiding very unpleasant surprises that don’t even regard published (known) breaking changes.
2
mudasobwa
Creator of Cure
Well, I pretty much always do this automatically on schedule in GHA. As a library author, I must make sure my library still works with the latest versions of 3rd-parties (because I cannot afford sticking people to the minor versions of my choice, let alone patches.) As an application developer, I want to make sure the latest code is used (because in Elixir world I barely met libraries which were updated for the sake of update, usually updates bring some goodness.)
Anyway, if you pin your apps to the patch versions (I never do,) your vote to the original question would be “I don’t care,” I believe.
0
DaAnalyst
I pin the app I am responsible for to the patch version for each framework we depend on because reliability and stability are what matters most once in production. Last thing we want when fixing our own bugs or adding new features is for library upgrades to introduce new bugs of their own. Frontend framework bugs are most subtle, difficult to detect with automated tests and often time consuming to pinpoint and fix properly. It’s also why any and all framework version upgrades are planned, scheduled subject to overall manual re-testing by our QA.
As for my vote, you can see above it was a resolute NO. I also explained why.
0
mudasobwa
Creator of Cure
Maybe it’s because I barely work with frameworks, let alone frontend frameworks. In the core distributed OTP world one needs the newest amendments to the libs too often in my experience.
During my journey into a world of core libs, I found that there is next to zero chance I would not miss something crucial from any library of my choice, and I would need to provide a PR myself (just to name a few: nimble_csv, nimble_ownership, nimble_options, mox, money_sql, mneme, xml_builder — were not satisfying my needs until my PRs,) or wait for the already provided PR to be merged and published and then nevertheless amend the version in my mix.lock.
Maybe that’s the main reason all my libs are backward compatible back to v0.0.1.
1
DaAnalyst
BartOtten
Developers tend to believe SemVer in that they pin their packages to major version ranges, expecting nothing to break (in their own app). They won’t get the update to v2 automatically when they pinned to v1. As expected.
There is a serious side effect though. As soon as the contract of a function used by 1% of the use base breaks, SemVer requires the raise of the major version number and breaking auto-update for the 99% use base. The very next patch won’t reach the 99% and as a result this 99% is subject to possible grieve when things go haywire in their systems due to an error in your lib which you already fixed…in v2.
Solution 1 is having a backport policy and take the burden of sticking to the policy to yourself.
[Insert meme “ain’t nobody got time for that”.]
Solution 2 is every project having an RSS feed and all the downstream developers subscribe to all feeds of packages they use so they are aware of every major release and they update immediately.
[insert meme about not so perfect world]
Solution 3 is the most popular: make clear you give no guarantees! In v0 you can break the 1% and have the 99% auto update. Now there might be inconvenience for the 1%, but it is a smaller use base and they probably will find out within a short time, when the CHANGELOG is fresh and the breaking change is at the top. Just cross your fingers the 1% use base is not that multi-billion dollar creditcard company which sees production servers err out. If it does, at least you can say “Not my fault, it was v0!”
Solution 4: as machines process version numbers far more often than humans; let machines do the heavy lifting. Version every function! This way machinery can tell each downstream exactly when there is an incompatible change because the downstream project is known to be affected.
There is also not a lot thinking involved. Changed function input or output? Bump function version (ABI) with 1.
This approach allows for far more flexibility, but that would require a new topic 
TLDR; greater than v0 versioning leads to branching and epoch does not seem to fix that.
1
BartOtten
Another solution is; don’t bother about version stability and use CI to always fetch the latest released / ‘prod’ tagged code and run the whole test suite. As long as the tests succeed the latest (released) downstream code is doing fine. If it breaks, you know in what 24 hour timeframe the breaking change was made and you can upgrade pronto.
No long upgrade sprints, nobody has to think about numbers, just a great incentive to write tests 
Os. This also solves the issue of “fixing a wrong behavior others depended on” as references in the blog post.
1
mudasobwa
Creator of Cure
As an author of many libs, used by many people I have never heard from, I can assure you: breaking the contract of the function in your library is a deadly sin which might be easily avoided. There are no curcumstances under which you must change the contract of the already existing function. Never.
I personally do for all my libs and all my projects. I have 2 CI tasks, one running ahainst mix.lock and another one running against no mix.lock. I also have an ugly script comparing the outcomes, that I am going sooner or later to turn into a mix task.
1
BartOtten
Define: must. The younger the lib, the more likely these issues arise. No point in having backward compatibility code for the next 10 years in a lib is 3 months old.
As a clean code base is a must, I do see a circumstance the contract of a function must be broken.
Or you resort to data versioning and migrations. But we both know that’s not a common practice (sadly)
2