<TimMc>
kentonv: I've heard a pretty convincing claim that major version bumps (in the semver sense) are just Bad, and that breaking changes should be accompanied by a change in the package name.
<TimMc>
(or we could all use something Nix-like, which might work too!)
<isd>
TimMc: I do actually want to move Sandstorm's build over to nix at some point, to help with reproducibility
<isd>
But yes, semantically major version bumps are more or less "a new library"
<isd>
(I think I got stuck getting ekam to build with nix the last time I tried)
<kentonv>
TimMc, I tend to agree, a major semver update should be treated as an all-new library -- and the old one needs to continue to be maintained. OTOH, maintainers need some leeway to make "minor" breaking changes without incrementing the major version... but it's hard to pin down what counts as "minor".
<kentonv>
E.g. a breaking change to a recently-introduced feature that almost no one uses yet, I would consider "minor". Though it's a lot better if any broken users would be detected at build time rather than run time.
<simpson>
It'd be nice if we could partition changes not as major/minor, but whether there's an automatic semantics-preserving transformation which implements the upgrade.
<isd>
During the run-up to go 1.0, they had a tool that you were supposed to run on your code after each upgrade, that adjusted for whatever language & stdlib changes they'd made.