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

Mini 2d ago

@david_chisnall @whitequark

tangentically related, theres an interesting set of papers nd research on encoding versioning at the type level, from ppl at the tokyo institute of technology

Some links:
https://prg.is.titech.ac.jp/projects/modularity/version-programming/

https://prg.is.titech.ac.jp/wp-content/uploads/2023/03/tanabe-phd-dissertation.pdf (https://github.com/yudaitnb/vl)

https://prg.is.titech.ac.jp/papers/pdf/pro2024-4-8.pdf (https://github.com/prg-titech/vython)

https://prg.is.titech.ac.jp/papers/pdf/sle2022.pdf (https://github.com/ansharlubis/batakjava)

i also did a bunch of design work on simmilar ideas but lost steam on my project

Programming with Versions – Programming Research Group

Show thread

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

@mini_ninja_64 @whitequark

Oh, interesting! Do they have a good solution to the diamond dependency problem? If my program depends on libraries X and Y, but X depends on Z version A, and Y depends on Z version B, but both X and Y expose types from Z in their interfaces.

I have some tentative ideas for how to solve this in Verona, but I’d love to see if someone else has a better solution already!

Show thread

David Chisnall (*Now with 50% more sarcasm!*)10h ago

@mini_ninja_64 @whitequark

I’ve skimmed a few papers and they seem to be not really handling that case. In particular, there are a bunch of issues that come up in structural (or late-bound dynamic OO) type systems.

For example, consider version A of some concrete type exposed from Z lacks a method, but version B adds it. This changes the behaviour of pattern matches on that type (and on interface conformance with structural typing). Library X using the old version must depend on the method not existing, whereas library Y expects to call that method.

I believe the solution to this requires viewpoint adaptation in pattern matching, which can be done by versioning interfaces and a little bit of trickery in the runtime. But I’d really love to see a type system that actually does this.

Show thread

Mini 8h ago

@david_chisnall @whitequark soz was distracted yesteqrday, I remember some vague mentions of the indirect dependency use problem, when i read the VL paper, if memory serves, my understanding was that the 2 re-exports would be distinct types due to the version constraint I would imagine, the 2 types to be incompatible in the X & Y interfaces?

yehh makes sense, my design at the time was v simple typing so avoided lots of problems but the thought deffo crossed my mind.