Scipy has a tried-and-tested release mode that closely mimics numpy: no semver, but rolling additions & deprecations & eventual removals.

With main now being at 1.9, certain deprecations are running into the problem of how to announce the point-in-time when a given feature will be removed. Since the possibility of Scipy 2.0 turned up in a discussion recently, coming up with good wording for this is tricky.

1. "X will be removed in the second release after SciPy 1.9.0"
   • currently used by DEV: stats: check for distribution/method keyword name collisions #13490 and MAINT: optimize.linprog: make HiGHS default and deprecate old methods #15512
   • IMO misleading/wrong because "second release after SciPy 1.9.0" == 1.9.2
2. variations on that theme are of course possible (additions emphasised for clarity)
   • "X will be removed in the second minor release after SciPy 1.9.0" (not a good fit because scipy doesn't use semver)
   • "X will be removed in the second feature release after SciPy 1.9.0" (suggestion by @mdhaber)
3. directly say "X will be removed in SciPy 1.11.0"
   • if a decision is taken towards releasing 2.0, this could be easily replaced

However, all those issues effectively boil down to an uncertainty about what to call the version after 1.9, hence this issue.

I had assumed (perhaps naïvely) that there's no reason to break the current scheme, not least because version numbers are not decimals and easily deal with two-digit minor versions, but perhaps more importantly, because numpy and cpython did so as well. My comment about this in the second thread was:

I'm thinking a putative 2.0 should come with some degree of "large change compared to 1.x", even if it isn't breaking anything**.

** as an example in terms of the kind of scope for a major bump that I have in mind, a current(ly-talked-about) candidate for cpython 4.0 is if/once the GIL is removed. On the numpy side, although there is an ancient, non-empty milestone, I'm not aware of current plans for 2.0 (though I did once wager that it'll come about eventually 😉) - comprehensively fixing integer promotion issues might be a candidate to go to numpy 2.0.

In other words, I would expect the 1.x series to continue indefinitely unless & until there's a large enough change that people feel deserves special attention by way of a major version bump.

Howevers, others might disagree; e.g. @ev-br said:

My personal opinion is that 2.0 is no special and I'd have a slight preference for 1.9->2.0. That said, it's not quite my hill so I'd go with a majority on this one :-)