Mastodawn

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 thread

David Chisnall (*Now with 50% more sarcasm!*)2d ago

@whitequark

I absolutely detest SemVer because it has no way of doing graceful deprecation, which arises because it conflates implementation and interface.

A library that wants to do graceful deprecation will have three releases, A, B, and C, where B introduces a new API and C removes the old one. C is a breaking change for anything coming from A. C is a breaking change for anything using B and not moving to the new interfaces.

You really want a set of SemVers, for each interface you support. So you actually have something like:

A: {1.0}
B: {1.1, 2.0}
C: {2.1}

I have never seen a system using SemVer that supports this. You can kind-of do it with UNIX SONAME and symlinks, where A has symlinks names libfoo.so.1, libfoo.so.1.1, and then B has symlinks named libfoo.so.2, libfoo.so.2.0, libfoo.so.1, libfoo.so.1.1 and libfoo.so.1.0, but I’ve never seen it done.

Show thread

sounddrill

@david_chisnall @whitequark I feel like pride version makes it a nicer experience despite not really fixing the things you mention lol