I feel that #4 (fix bug and add flag to roll back to old behavior) is best.
About the alternative implementation, I am fine adding it to 3.x and 4.0,
but should treat it as a different path disabled by default that you can
opt-into, with a plan to opt-in by default "eventually".
On Wed, Nov 18,
Perhaps there might be broader appetite to weigh in on which major releases we
might target for work that fixes the correctness bug without serious
performance regression?
i.e., if we were to fix the correctness bug now, introducing a serious
performance regression (either opt-in or opt-out),
This is complicated and relatively few people on earth understand it, so
having little feedback is mostly expected, unfortunately.
My normal emotional response is "correctness is required, opt-in to
performance improvements that sacrifice strict correctness", but I'm also
sure this is going to
It doesn't seem like there's much enthusiasm for any of the options available
here...
On 12/11/2020, 14:37, "Benedict Elliott Smith" wrote:
> Is the new implementation a separate, distinctly modularized new body of
work
It’s primarily a distinct, modularised and new body of work,
