✧✦Catherine✦✧2d ago

people: ask their dependencies to follow semver, for fuck's sake already
also people: make a surprised pikachu face when the major version is incremented with every release

(i have been both, at times. this is about me. this is also about others who i've seen be a lot more militant about this issue)

the thing is, if you have a sufficiently complicated application it is not feasible to determine what is a "breaking change" or not. this complexity limit kicks in long before you get to a "browser" or a "JIT compiler" but it is definitely well applicable by that point

i think what people mean when they do both of those things are a mix of "please stop adding features entirely. only fix bugs" and "please only make changes i like, but not the changes i dislike" depending on maturity level. that's not really how open source software works though

Show threadGlyph2d ago
@whitequark this is exactly why I am a bit of a CalVer zealot. abandon the illusion. only by freeing yourself from desire can you achieve enlightenment
Show threadGlyph2d ago
@whitequark in python (and many other languages) you can’t even get your tools to produce something as crude as an soversion. If we had a robust tool that could do something like “make a DAG of all publicly defined names and tell me if anything has been changed or removed between these two git tags” then we could maybe TRY to do semver but as it is I cannot imagine anyone doing it correctly
Show thread✧✦Catherine✦✧2d ago

@glyph I think that's a really silly absolutism. who cares if all the names are there if the types have changed? who cares if the types are the same if the behavior changed? this exact line of thought implies you can never have any notion of compatibility at all

i think of version numbers as a communication tool, or sort of a filter: they tell you if shit's definitely broken or maybe fine. this is a useful signal

Show threadGlyph2d ago
@whitequark I may be making some "live internet-facing service using libraries" assumptions about how updates need to be managed, which is to say, you have some compliance and possibly legal obligations to upgrade to new security supported versions in a timely way, every application is in its own venv (and probably its own container or even its own VM), there's a staff of people doing regular maintenance. for dependencies of such environments semver doesn't make sense
Show threadGlyph2d ago
@whitequark the social function semver serves in that context is "I want to use version 3 forever because I don't give a shit about the health or development direction of the projects I depend on, I just want free security support where I can do no-look upgrades for eternity". every time you do a "breaking change" (which is to say: remove any deprecated name) you bump the major version which means all your dependents stop getting updates and then they get mad
Show threadGlyph2d ago
@whitequark pinning to a major version in this context is just allowing downstreams to accumulate pain to turn every "major version" upgrade into a looming catastrophe when the last major version goes out of support. meanwhile you end up having to support 9 major version branches, and if you don't, Red Hat comes along and starts pretending you have security support for those versions too
Show thread✧✦Catherine✦✧
@glyph yeah so what I've seen with my downstream is that if I break too many things in a way that's annoying they just pick a version they like and never upgrade at all. which effectively results in a fork
Mar 27 at 11:54pmWeb