I think Nelle is concerned that doing it once (and surviving 😉) is enough to trigger a mindset change in the core developers that breaking releases are Ok, and thus can be done more frequently. For example, matplotlib 1.0 was released in July 2010, 2.0 in January 2017, then 3.0 in Sept 2018. 😬

In private discussions with Nelle she suggested that she *also* didn’t like skimage2, and in fact would advocate for gradual but breaking changes — meaning, at some point, `filters.gaussian(image)` becomes an *error* without `filters.gaussian(image, preserve_range=True)`. Then in later versions we deprecate that arg. This can all happen very slowly but the key is that the silent behaviour change is extremely noisy somewhere in the middle. You end up with a silent behaviour change but not before everything breaks loudly for an as-yet-unspecified period of time. The key is that people pay attention to errors, but tend to ignore warnings.

Now, for some, that *final* state, that 0.19 code ends up working differently in 0.23, even though it was broken in 0.22, is enough to say, let’s go with new-name/new-import. That’s fine.

But for others, one big issue with 1.0 is that it was impossible to warn loudly enough. So I’d like to propose what I call the chaotic good modification to the SKIP as an option:

- 0.19 is released, no deprecations, no nothing, everything is as it always was.
- over six months, we break everything we want to break on master on the road to the brave new 1.0 world.
- once we have everything where we want it, we release 0.20, identical to 0.19 but with a warning to migrate. We simultaneously release 1.0b0, so that people can migrate and depend explicitly on scikit-image>=1.0b0.
- after six months, we release 0.21. This is a completely broken release that does not import: it raises an exception that you *must* either migrate or pin to continue using scikit-image.
- after an unspecified period of time, we finally release 1.0.

Releasing a broken package is definitely chaotic, but it *does* force people to pay attention, and if the error makes the fix obvious enough, people are ok with this.

To me, this really dramatically diminishes the risk that the transition will go unnoticed by most people.

The major downside relative to the new package/new import solution is still that you *do* make 10y of stack overflow answers obsolete in some form or another. And, to be honest, many people don’t install from requirements files, they install with `pip install [package that I am reading about for the first time]`.

Anyway, I think that in a perfect world, Riadh, yes, the version bump should be enough signal. But it’s not a perfect world and users have expectations. I don’t think it’s good enough from a “customer satisfaction” standpoint if we just say “sorry that you didn’t read the fine print on the label and are now missing an eyeball” — we should indeed try to put more measures in place than a small label to prevent people from poking their eyeballs out. 😜

As a real-world example, a bunch of people in Australia got burnt by their thermomixes when they sloshed too much hot liquid around, even though the instructions say don’t use turbo mode on hot liquids. Thermomix ended up shipping TM5s (new model with more safety features) to everyone who purchased a TM31 in the last x months of its life. (Including yours truly) Moral of the story: let’s try from the beginning not to burn our users even if they didn’t read the label. 😉

Although, the counterpoint: it is super annoying that the TM5 holds the lid closed for 8 seconds now before letting you open it. 😂


On 21 Jul 2021, at 7:06 pm, Riadh <rfezzani@gmail.com> wrote:

Le 21/07/2021 à 10:55, Nelle Varoquaux a écrit :

I would be a bit cautious a bit about the "changes are not silent because the major version number is upgraded." That opens the door to doing a lot more major versions in order to "allow" for API breakage when it could be avoided.

As a user, I find that it would be nice if my code that only depends on numpy, scipy, and matplotlib that I started at the beginning of a research project with up-to-date packages also worked at submission time with up-to-date versions of those packages with minimal changes to the code :p


That's not what I am calling for, we are talking here about a first major release after a years long development  period.

I am absolutely not pushing for a faster release pace ;)


scikit-image mailing list -- scikit-image@python.org
To unsubscribe send an email to scikit-image-leave@python.org
Member address: jni@fastmail.com