I want to strongly suggest against having two branches.
That said, the LTS release really took a lot of maintenance power, and involved a similar "feature/bugfix" parity.

Do i understand that "strict deprecation" is something like what we have been doing already?


On Wed, Mar 4, 2020 at 8:00 PM Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Wed, Mar 4, 2020, at 15:01, Juan Nunez-Iglesias wrote:
> I might not be getting the full picture here: returning Bunches instead of (in most places) NumPy arrays would in itself be a breaking change? Similarly, one of the big changes we are proposing is returning an array of floats that is *not* rescaled to [0, 1]. That is, we want to still return a NumPy array (whether that is the plain array or an attribute in the Bunch) but the values in the array will be different. I don’t clearly see how Bunch solves that problem?

There are at least two considerations here:

- We want to stop coercing image data to a certain range based on the data type of the input. This will be a breaking change, overall, unless we introduce the `preserve_range` keyword widely.

- We would like to make, consistently, most functions be of the form:

 output_image = function(input_image)

This makes for easy construction of pipelines:

 output_image = first_func(second_func(third_func(intput_image))

In cases where additional calculations are made, we want signatures of the form:

 output_image, additional_namedtuple = function.extra(input_image)

[Exactly how the calculation of additional_namedtuple is triggered is not set in stone; the `.extra` attribute on functions was one suggestion of how to do that easily.]

The usage of named tuples / bunches / data objects will be an integral part of the design.

Best regards,
Stéfan
_______________________________________________
scikit-image mailing list -- scikit-image@python.org
To unsubscribe send an email to scikit-image-leave@python.org