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.

Reply via email to