Re: [tap] Rethinking the TAP version

[Michael G Schwern <[e-mail]>]

Aristotle Pagaltzis wrote:
> * Michael G Schwern <[e-mail]> [2009-02-20 01:00]:
>> I propose that the version number change to X.Y where X
>> indicates the compatibility series and Y indicates an
>> incremental, but still compatible, revision. Everything that
>> can read protocol 2.0 can read 2.1 and 2.13 and 2.99 but if a
>> 2.x parser sees 3.1 it knows it can't handle it and can act
>> appropriately. Similarly, a 2.x parser is not guaranteed to be
>> able to read 1.x.
> 
> It sounds good in theory, but doesn’t work out very well in
> practice. It’s only a win if you want to break backcompat often,
> which is not a smart idea. But if you revv that major version
> only once in every decade, you effectively create a new protocol
> each time, not a revision to the old one. Going from `TAP version
> 1.13` to `TAP version 2.0` is effectively indistinguishable from
> going to `TAP2 version 1`, and you don’t need any version check
> code to make consumers fail to parse future TAP versions.
>
> (That’s how we handled it in the Atom WG too. There’s no format
> version in Atom; if backwards-incompatible changes are ever
> necessary, the XML namespace will change, so old consumers will
> fail to process the document at all.)

I get what you're saying.  The problem is we have no namespace.  Technically,
because we ignore anything we can't parse, everything is a TAP document.
There's currently no way for a TAP parser to say "I can not parse this".

TAP parsers will ignore any line they don't recognize.  Upon failing to see a
TAP version they will assume it's TAP version 12.  At best, they'll see a
suite with no tests and fail.  At worst they'll only see the passing tests,
miss new-style failures, and pass what should have failed.

So we need some way to indicate a backwards incompatible change.


-- 
<Schwern> What we learned was if you get confused, grab someone and swing
          them around a few times
        -- Life's lessons from square dancing