Michael G Schwern wrote:
I don't have a long term solution for users of test_diag(). I'm entertaining
ideas. "Don't change the failure output" is not one of them. One temporary
hack is to parse the test_diag() input, look for attempts to match the old
Test::More diagnostics and translate it into the new format/regex/whatever.
Since the old format is very regular this should be fairly straightforward.
Define a new version of TAP with a single change.
Specifically, emit a version number in the TAP output that describes the
version of TAP that's being emitted.
Everything that's currently emitted/supported is v1. Any changes after
that, just bump the version number.
I'm in two minds as to whether or not the version number should be a
traditional software version number (x.y.z), or whether it should just
be an incrementing integer. x.y.z opens us out to arguments about
whether a change to the format is a minor or a major change, while an
incrementing integer would avoid that fuss.
This would then make it possible to
a) Add new features/change the format without breaking tools that read it.
b) Have T::H and friends emit various versions of TAP depending on what
the rest of the tester's toolchain can read.
I discussed this with Andy over IM yesterday in the context of another
requirement that I have, and he's not keen on extending TAP in this way
on the basis of one request (i.e., mine). Anyone else think this is a
good idea?
The field of CS is littered with examples of protocols that have had to
be extended beyond the original vision of their creators. How the
extension has been handled, and what sort of kludges have been necessary
to handle it is in large part down to how extensible the format was
designed to be. c.f., SMTP/ESMTP, and the laughable HELO/EHLO distinction.
N
PS: As an example of something I'd like to see 'cleaned up' in TAP -- I
have a lifelong aversion to 'syntactic comments', i.e., comments that
actually have a meaning to something parsing them. Accordingly, I'd
love to see "not ok 2 # TODO bend space and time" become "todo 2 # bend
space and time" in some future version of the format. But there's no
way that can happen without a sensible mechanism for extending the
protocol, and advertising the extensions.