On Mon, Mar 2, 2020 at 9:30 AM Juan Nunez-Iglesias
Dear scikit-image community,
Last week, Stéfan van der Walt, Emmanuelle Gouillart, Alexandre da Siqueira, and I met at UC Berkeley to discuss the future of the library. For part of the meeting, Kira Evans from napari and Tom Caswell and Hannah Aizenmann from Matplotlib were also attending, and provided valuable feedback.
Our unstructured notes are available here:
https://github.com/scikit-image/meeting-notes/blob/master/2020/2020-02-27--B...
The short of it is that we agree that it is a good time to aim to make a 1.0 release. As a team, we have developed an increasingly good idea of the pain points of the library, vs the things that work. Additionally, for the next year, thanks to CZI, we have ~1.5 people paid to work on scikit-image, so the hard work of major API restructuring is achievable.
Our proposal is that **scikit-image 1.0 will contain breaking changes.** This is because, in many cases in our API, we want to change the return value of a function without changing its signature.
Just in case you're not aware of it, there's a nice Bunch design pattern that we've been discussing for a long time for scipy.stats, for the same reason of adding more return values. It allows you to do this in a backwards-compatible way, see https://github.com/scipy/scipy/issues/3665#issuecomment-451038177. The main idea is to freeze the number of arguments returned by tuple unpacking, and have namedtuple-like behavior otherwise (which is preferred for new code). Besides not breaking user code, the advantages would be to be able to make changes incrementally, also post-1.0. Cheers, Ralf This is difficult to achieve with deprecations — it typically involves
creating a new, mostly useless keyword argument to signal the new behavior, that later needs to be removed. Additionally, allowing breaking changes will enable us to "clean up shop" and clean up the API a *lot*.
So, how will we minimize the impact of this proposal to the community? * this email: we want your feedback on this proposal! Ultimately, this will become a SKIP that will need to be approved by the core developers. https://scikit-image.org/docs/dev/skips/0-skip-process.html In the meantime, nothing is set in stone. * create a transition guide: for every change, analyze how user code could be affected (errors, strange results), and produce an item in the guide for how to transition 0.x code to 1.x code. * extreme communication: we plan to announce our intentions far and wide, including this mailing list, others in the ecosystem, Twitter, and at conferences. For users that just want their code to keep working, pinning to "<1.0" will prevent their code's behavior from changing without warning. * pre-releases: we will make one or more pre-release of 1.0 so that users can test their code before the release comes out officially. * feature parity: we will time 1.0 to be simultaneous with a 0.x release, so that users can keep using the 0.x series without missing out on mission-critical features.
In the coming days, I will be creating a few issues related to this proposal on GitHub at https://github.com/scikit-image/scikit-image, together with a corresponding GitHub Project. You can find all issues related to this transition by using the "1.0" tag. Those will be the right place to discuss specific API changes that we are considering. This thread or the meta-issue on GitHub will be the place to discuss the process of the 1.0 release overall.
Questions? Concerns? Write us an email, catch us on Zulip, or comment on related issues on GitHub.
Thanks for reading!
Juan. _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org