3 ms·
Of course coming with the _major_ caveat that the interface and behaviour[1] of the dependency is absolutely stable for the entirety of the "major version". I'
by bobnamob 2y ago
Of course coming with the _major_ caveat that the interface and behaviour[1] of the dependency is absolutely stable for the entirety of the "major version".
I'm an advocate for this style of library/dependency development, unfortunately in my experience the average dependency doesn't have the discipline to pull it off.
[1] https://www.hyrumslaw.com https://www.hyrumslaw.com
- zo1 2y agoI don't want to "pull this off", nor do I want to expend the time/energy to do so. We're not Microsoft with effectively infinite budgets, nor are we Elasticsearch/Grafana Orgs with metric oodles of developer-hours, and 50k+ github star mindshares-worth of evangelists behind us to document and tutorialize every tiny little feature in a cookbook or doc website. Code changes, and it's kinda silly to expect interfaces to be locked in place as that'll stifle development for even small-ish features. Does that mean every minor version or commit will change fundamental or large parts of the codebase? Probably not, but it's a sliding scale and people seriously need to find something better to do than writing Yet Another Python Package Manager. I use the term "we" loosely here ofc in the context of this mini-rant.
- andrewchambers 2y agoIf you are breaking the api it isn't that hard to add a new one instead of butchering the old one. If it really can't be done then you aren't really shipping a library that is meant to be depended on.