develooper Front page | perl.cpan.workers | Postings from May 2015

On Not Merging new and old behavior ( was Re: Test-Stream + MongoDBscalar refcount issue )

Thread Next
Kent Fredric
May 2, 2015 15:12
On Not Merging new and old behavior ( was Re: Test-Stream + MongoDBscalar refcount issue )
Message ID:
On 3 May 2015 at 02:32, Aristotle Pagaltzis <> 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

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.



Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About