I believe this was the following keynote: jupytercon2025.sched.com/event/28U0G/...

I don't know where the data were from, but I know that Jason will!

Yeah, I think we're pretty aligned on the nature of the problem! I don't feel confident that I have the golden bullet either, but I am enthused that more of us are talking about it in general -- that's definitely an improvement.

This is harder in semver - how do you encode/schedule N breaking changes ahead of time, whilst also making room for an undefined number of new features etc.?

I think that's a nuanced point that won't come across clearly here!

Yes you could do that! And we used to do that in awkward array.

The benefit to use calver is that you lose the misplaced assumption and force people to refer to the document that you would author in both cases. Additionally, in awkward we used time-based compatibility, so calver would have helped!

In theory each month could be a breaking change, but by defining a schedule you can allow people to predict the calver numbers that these correspond to. With semver, you lose some of the segments to semver semantics.

I agree in part, and I don't think calver is perfect either. The point is more nuanced though - the idea is that you can make breaking changes for different parts of the code base at different times.

So, I reckon you might want to identify the persona of the package author that would use effver, and ALSO speak to how consumers of effver-sioned packages should reason and use this (contrasting with semver, probably)

You might also wish to reference examples of where semver failed in practice?

What I don't love about effver is that it surfaces the hand-waviness of this, but doesn't make it easier to trust a constraint.

That's why I tend to like calver on the basis that you can literally pre-define what a breaking change is, and when you'll make it. But, it's more work.

That means semver is really there to help people apply upper AND lower bounds to version constraints.

My suggestion for introducing people to effver is perhaps to center this point earlier on:

The whole point of ascribing meaning to version numbers is to permit someone to say "I'll use a range of versions, so long as they work".

The "whether they work" part is doing a lot of heavy lifting.

- e.g. big projects that have breaking change windows (where they cram together a bunch of breaking changes)

- at this point, it's fair to compare semver with other schemes that also require additional context to interpret version numbers, e.g. calver, effver, zerover, etc.

- good semver usage *requires* that you author some additional document that defines the bounds and intention of compatibility

- it really suffers for big projects (as the number N of distinct pieces grows, the likelihood that successive versions are "breaking changes" grows), i.e. as N→∞ you end up with something equivalent to monotonic incrementing numbers

- it gets worse with languages like Python where APIs can be tested far more deeply (e.g. introspection)

The way I've been thinking about versioning is as follows:
- semver is fundamentally a lie that we tell ourselves. It presupposes a lot of ill-defined notions of compatibility.

Lol, listing my blueksy in my bio and not logging in for a week!

I'd love to give this some more thought to articulate my feelings on this more clearly. Let me get back to you!

Ugh this was so useful. Time for a new extension...

www.technologyreview.com/2025/05/20/1...