It sounds like a lot of work to maintain two packages (fails criterium (3)). Especially since both will need to be updated continuously to satisfy criterium (2) — ensuring that most users land on skimage2.
This is a problem; you will find that most people just stick with skimage1 then and don’t transition.
Or, you break the skimage1 package to force them to transition, and then none of their old code runs.
I don’t think it’s super hard to make skimage2 compelling enough that people want to try it. Addressing some of regionprops’s warts is sufficient to make me move 
I’m not wedded to the two packages, but it doesn’t seem to me to be that much worse than having them be “siblings”. Either way you have two packages, it’s just how you distribute them that’s different?
I think it’s important to have a separate skimage2 package because otherwise eventually pip install scikit-image will break import skimage, unless we decide to maintain it ad-infinitum? Whereas if they are separate packages, then pip install scikit-image will eventually fail e.g. for new Python, but it’ll fail at install time, and we can tell people “you need to use Python 3.12 or earlier, only skimage2 is compatible with newer Python”, but those old envs will “just work”. Otherwise we’ll need to tell them to pin? Which is SKIP-3-ish?
People can always install older versions of scikit-image if they need to. What we’re dealing with is the same problem users have right now when we make breaking API changes over several releases: no matter how slow we go, eventually you cannot run the latest package with old interfaces.
I think it’s really very important to take your users on the journey with you, and not to leave them behind at 1.x. Users are hard to come by and easily lost if you don’t handle these types of issues with the necessary care. Helping them transition their code to be in line with our latest APIs—that is, the ones we support!—feels respectful. I don’t see how we can do that easily with two packages; do you?
1 Like