Hi. On Tue, Jul 20, 2021 at 12:35 PM Riadh <rfezzani@gmail.com> wrote:
Hi,
Le 20/07/2021 à 12:21, Matthew Brett a écrit :
I think the underlying problem here is that developers generally have a very different set of instincts to users. Developers typically update their machines often, don't worry too much about code breaking, and may (although, surely this is uncommon?) pay some attention to changes in major version numbers. I think users generally do few of those things. I'm a developer, and I certainly don't expect huge API changes with changes in major version numbers, even though I know about semantic versioning. In practice, I think it is very uncommon to make large API changes between major versions, and especially, Hinsen-breakage API changes.
I agree with you, developers may even don't worry about code breaking, as they may consider it as challenges to solve :D
So I think it's fairly typical for developers to think 'What's the problem?', because this kind of problem isn't a problem for them. But I think you'll find it is a major problem for almost everyone who is not a scikit-image developer, and does use scikit-image, and especially those who are not reading this email thread.
This is not my reasoning: my point is that it is in fact not a problem since a simple solution exists and is identified: communicate and offer a clear documentation to the community.
Just to return to the paragraph above, I bet that "users not adopting modern python programming convention" is a reasonable description of your average user.
You are right, and I bet that a large majority doesn't maintain a script or a package that will break with the v1.0 release.
Juan previously said:
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 there some controversy about how much code would break? Juan suggests that nearly all scripts will break, and indeed, that's a feature because then they won't get Hinsen breakage. I'm not sure I agree with Juan's point there - I bet you'll find people fixing the errors, but not noticing the Hinsen breakage, but that's a side point.
Users usually use the API as it is when they are coding. And more "serious" coders usually care about code breaking, and if they do, they pin they dependencies versions. If they don't, I am pretty sure that they will be happy to learn how to do it ;)
But - to return to the practical point - what is the extra work, and fracturing, that you see for the skimage / skimage2 option?
If you don't want to maintain 0.18 / skimage - then no problem - just abandon skimage and work on skimage2.
If you do want to backport fixes, then you might (or might not) find it easier to use skimage as a namespace, and use the current skimage2 as the home of the real code.
Maintaining a second package also means managing the infrastructure (Git, doc, CI, deployment...)
Now the question again - what is the real advantage of calling the new version skimage 1.0 instead of skimage2? I mean, in what sense is the community less fractured? At the moment I am stuck with the implausible answer that it's a good idea to break lots of code to force developers onto the new skimage 1.0 version from the old one. But you can't mean that. So - can you say more about what you do mean?
But what is the advantage of skimage2 vs skimage v1.0 if code break is a fake problem? I still convinced that we are not breaking code:
```
conda create -n old_skimage_env skimage=0.18 conda activate old_skimage
python my_old_scipt_broke_by_v1.py
```
And finally, I am not sure, as a nostalgic skimage user, to be happy to call `import skimage2` :)
I can see that argument, but is that argument enough to justify breaking a large proportion of current user code? Cheers, Matthew