Hi, On Tue, Jul 20, 2021 at 11:03 AM Riadh <rfezzani@gmail.com> wrote:
Hello every body,
and thank you all for your feedback!
I am sorry but I don't really understand all the worry about code breaking... Versions 0.19 and older will not disappear when v1.0 will be released!
I bet that all of our understanding will rapidly increase when it happens!
Python environments are well adopted and installing specific versions of packages is easy now (pip, conda...). Moreover, we can still point users to good tutorials on how to use them.
Versioning in general is getting more and more popular in the scientific community as it helps results reproducibility (code and datasets versioning). In scikit-image, we adopted the semantic versioning as it is largely adopted in the engineering community. This convention manages API breaking and that's what we are doing by releasing v1.0
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. 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.
I don't think that maintaining two packages is a good deal: forking only for users not adopting modern python programing convention is not reasonable to me.
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. 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. 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? Cheers, Matthew