On 3 May 2015 at 02:32, Aristotle Pagaltzis <pagalt...@gmx.de> wrote:
> That feels like “this is the point in our programme where we rethink the > approach” to me; like a strong hint that the journey went down the wrong > turn somewhere quite a ways back. > I am in agreement, and a few of us are now exploring the idea I believe you were in favour of earlier, doing it in a separate namespace. That there are likely equally as many as heisenbugs like this that only show up 1 in a million times is a prospect I really dislike, especially given we still have no idea why its happening. I would be fine in investing that level of debugging effort if we had published code that was already in deployment, but having to debug that in a prospective release ? That .... that sounds dangerous to me. And more, not only is our attempt at perfect backcompat failing us, the goal of mixing perfect backcompat and radical API changes screws us in several ways. One significant one being that the new technology has to pay the technical debt of all the bugs and mistakes in the old technology. In the last day, my opinion has switched from "It must work together out of the box" to "It must not work together at all, unless somebody who wrote a test explicitly declared they wished it to work together". Its better to explode outright and tell people "No, we cant guarantee this test will do what you think it will" than to muddle around and *hope* it "just works". Hope is not sufficient for the level we are at. We have to guarantee we don't break anything, and unlike the usual "perfect is the enemy of the good", we have no such quandry. We *can* get the new stuff with no risk of breaking the old stuff. The biggest conceptual downside of a "Force no compatibility unless requested" is the potential that downstream ecosystem testing tools may, in turn, make bad choices about future support schemes. That is, conceptually, its possible that a misguided author of a distribution at the same level as say, Test::Differences, thinks it wise to simply rewrite their existing code in the new framework. In a "try work if possible automatically" environment, that change would imply that existing users of Test::Differences would get the "new" test system without changing their code, and that is unacceptable. It is admittedly not *our* problem if TD makes a bad choice here and does the wrong thing, but the right thing to do must be clear and encouraged, and if authors of other important toolchain modules see fit to intentionally do the wrong thing and break their dependants, and circumvent our strictures that serve as a deterrent, then we cannot do anything about that. They can arguably do lots of dumb things unrelated to Test::Stream, and the problem is unrelated to how we must proceed. It is critical that _we_ must not break things. IF we establish a system not to break things, and documentation, processes and code to encourage other people doing the same, then it is not on our heads if people go in a different direction. But we MUST be the gold standard. Because literally everything else Perl is relying on us. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
