
Hi, On Tue, Jul 20, 2021 at 2:22 AM Juan Nunez-Iglesias <jni@fastmail.com> wrote:
Hi Stéfan, Matthew,
Thanks Matthew for weighing in. Stéfan, no worries about having second thoughts — the purpose of the SKIP process is to account for these! But, my responses below — I’m still in favour of the SKIP.
There are two main concerns: breaking the Hinsen rule, and supporting users through the transition. Regarding the 1st:
Perhaps we should reconsider biting the bullet and going through the slower, trusted deprecation process? It is true that we are short on person-hours to do the work, but if we estrange part of our user base increasing volunteer time will become even harder.
I think this is actually *counterproductive* in the context of the Konrad Hinsen rule: if we change slowly with a deprecation path of adding `preserve_range=False` whose default value migrates to True over two versions, then *you end up breaking the Hinsen rule*, just over a slightly longer timescale.
And you don’t get your compatibility layer — earlier versions of the library don’t have `preserve_range` so you can’t easily support the later version and the earlier version simultaneously.
In contrast, if we go with the 1.0 approach and bundle a large number of breaking API changes, the odds of breaking the Hinsen rule are much smaller: almost all skimage 0.x scripts will fail with skimage 1.0.
Is that really true? That you'd expect nearly all scikit-image scripts to fail with errors on version 1.0? The wisdom of the Hinsen rule, I think, is the understanding of how much scientific software exists as scripts, or de-facto packages, but without little formal maintenance, such as specification of package dependencies. If you make all these break (if they are lucky) or give completely wrong results, it's hard to imagine you aren't going to cause significant damage to the rest-of-iceberg body of users who are not on the mailing list. I guess the next question is about skimage2 and fracturing of the community. Could you say more about what this means in practice? I mean, in what sense will the community be more fractured compared to the skimage2 alternative? At the moment this is hard to understand, because you are saying that you are expecting almost no packages to be simultaneously maintaining code for scikit-image 0.18 and 1.0 - and that you are accepting that a lot of current code is going to break or give silently wrong results. That seems like community fracture plus a lot of lost goodwill - compared to the situation where those who know what they are doing can just shift over to skimage2. I suppose you could reduce maintenance by having skimage import skimage2, as in: def some_func(data): fdata = scale_to_float(data) return skimage2.some_func(fdata) Then the skimage package becomes your v0 namespace. Cheers, Matthew