✧✦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 thread✧✦Catherine✦✧2d ago
@glyph yes, you are, which is my point. Amaranth is (in the vast majority of contexts) not a security-relevant application and if Python was more like Rust in terms of how it manages dependencies, it would have been actively desirable to have some stub library that lets you link together modules built with different versions of the language; typically if you make a HDL module, you verify it and then you just don't touch it ever. (this is not the only possible workflow, but this is the de-facto standard workflow in the industry, and a lot of the time it's close to the best you can do because the interface of the module, including the bugs, gets implicitly embedded in projects like "Linux" where if you change anything your actual end users will see an update maybe in five years)
Show thread✧✦Catherine✦✧2d ago
@glyph the other thing is that I guess this makes me not particularly interested in using Twisted (I have no other context here) because I don't want to be on call for this any more than humanly feasible, and I am not a startup that can afford to burn infinite VC cash chasing upgrades
Show threadGlyph2d ago
@whitequark to be clear, we don't just do "calver, but every micro-release breaks everything", we have a rolling window where every release (potentially) removes deprecated stuff, and deprecates new stuff. if you have tests and they run without warnings, you should be able to upgrade without any work. the workflow for downstreams (who, again, must be upgrading periodically anyway) is "run & fix tests until no warnings, upgrade one version, repeat"
Show threadGlyph2d ago
@whitequark in practice, among our cohort of comparable dependencies we have a reputation for extreme stability because we don't have these big major-version jumps where huge arbitrary clumps of stuff all break at once, every individual upgrade is usually between "zero" and "trivial" in terms of the amount of work it takes
Show thread✧✦Catherine✦✧2d ago
@glyph yes, but your test workflow is of a kind that doesn't involve "you probably have to run it on a real hardware, and maybe plug in an oscilloscope and spend a day chasing a single-cycle problem resulting in updating an expression somewhere in the guts of an application"
Show threadGlyph2d ago
@whitequark indeed not. I am pretty impressed that you get people to upgrade at all in the face of that. do your downstreams just pick a major version and ride it out until the end of support or can you convince them to upgrade major versions? and what kind of stuff do you change in minor/micro versions that don't risk breakage?
Show thread✧✦Catherine✦✧2d ago

@glyph I am impressed too, hah. I think this works because I'm really zealous about either not breaking stuff at all, or breaking it in a way that's legible: where you get a diagnostic pointing you to the place that's broken and, usually, telling you exactly how to fix it and what the rationale is

it's a mix of several things: some downstreams pick a major version and ride it out, some run against main, some test against both main and last major

(keep in mind that Amaranth has a 0.x.y version, but x is de-facto major and y is de-facto micro; there is no minor because there are neither resources nor justification to do minor releases)

micro versions exist for two things:

  • fixing regressions that should've never gotten into the release in first place
  • exceptionally, making backports that are necessary for ecosystem health, like introducing an interface that an accepted RFC places in the next release so that people can upgrade in a more gradual way. this doesn't happen a lot.

one thing that not using calver allows is having a predictable deprecation train. there are currently 0 people working on Amaranth full-time. the RFC can say "we deprecate this over two x increments" but it can't say "we deprecate this over the course of the next year" because truthfully who knows how much stuff gets implemented over the next year?

Show threadGlyph2d ago
@whitequark this is surprisingly close to where twisted landed despite the very different requirements and ecosystem pressures. our version of a "legible break" is that we try to never ever touch the presence or the signature of a public name; changes are supposed to show up in the form of new name introduced / old name deprecated / (mandatory minimum delay) / old name removed. the minimum delay is 2 versions or a year, whichever is longer
Show threadGlyph
@whitequark we have a lot more flexibility on "behavior" and sometimes security fixes require behavioral changes, but in practice we really rarely make intentional behavioral changes that actually break stuff. if there's a regression we'll do a micro-version that fixes the behavior but those are extremely rare nowadays, since there are a few downstreams that test regularly against trunk and report bugs (so when stuff like https://github.com/twisted/twisted/pull/12599 happens it's rarely in a release)
fix optionsForClientTLS to negotiate ALPN again by glyph · Pull Request #12599 · twisted/twisted

Scope and purpose Fixes #12598 Add a few words about why this PR is needed and what is its scope. If the associate ticket(s) fully explain the need you can just refer to it/them. Add any comments a...

GitHub
Mar 28 at 12:12amWeb