I agree with all your concerns Stefan, my only point is that the changes are not silent: the major version number is upgraded and that's, I think, a sufficient indicator telling that things may break in old code if someone tries to run it with the new version.
I am not against adding warnings or whatever we think is necessary to inform users about "silent changes of behavior", but I am convinced that package or import renaming is a bad move.
Riadh.
Scikit-image depends on Numpy/Scipy that are already Hinsen-rule-breakers.
I don't think NumPy and SciPy are Hinsen-rule breakers. There's a very strong sense in both communities that that should not to happen. Again, to be specific, here I speak of *silent changes of behavior*, which Matthew dubbed the Hinsen-rule.
Hinsen himself has *many* requirements of software, and I'm sure NumPy and SciPy don't fulfill all of them.
Back to our discussion, changing the package name or the import name will impact all our users, while only few of them are concerned with the Hinsen rule. Let's guide those ones to use virtual envs and version pinning that will definitely help them in developing reproducible research.
The changes proposed will impact all our users either way; there is no option not to be concerned. It will bite you if you have *any* pre-existing skimage code. What is being argued here is that we make it explicit when we break our contract.
We have no way of knowing who the users are that "need help" in learning how to pin versions etc. In fact, those are exactly the users you will not see on a mailing list or forum. The only way to help them is by letting the software speak for you.
If we really want to help reproducibility along, then we should build a reliable ecosystem of software that treats its users, their work, and their time with respect. By making our changes explicit, we do our best to ensure that invalid results don't accidentally end up where they shouldn't (in publications, for example).
Stéfan