[tap] Rethinking the TAP version

Michael G Schwern <schwern@pobox.com> Thu, 19 February 2009 23:57 UTC

Message-ID: <499DF1D6.9020009@pobox.com>
Date: Thu, 19 Feb 2009 15:57:10 -0800
From: Michael G Schwern <schwern@pobox.com>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: tap@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [tap] Rethinking the TAP version
Precedence: list

After I was the one who pushed for a simple integer TAP version, I now want to
argue for an X.Y format.  Why?

In Oslo we went nuts trying to figure out a syntax for sub-plans that was
elegant and backwards compatible.  By "backwards compatible" I mean that the
suite passes and fails in the same way.  Diagnostic information may be lost,
and even individual test results may be lost, but you still get that critical
pass/fail across all versions.

I see this becoming more and more of a problem as time goes on.  At some
point, we're either going to want to break compatibility or the protocol will
stagnate and die.

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.

This gives us a lot more latitude for future change.  It enables a sane
deprecation cycle.  It allows readers to explicitly know what it can and can
not handle.  It lets us correct some of the mistakes of the past and build on
our experience for the future.

Can I get some +1s?


PS  My objection to X.Y versions has always been that what X and Y mean
changes from person to person [1], so you can't reliably convey any meaning,
and humans aren't going to check to see what it means for YOUR particular
project.  But we can define what X and Y mean in the protocol, and we have a
program to interpret it.  No ugly flesh bags need be consulted.


[1] http://use.perl.org/~schwern/journal/35127


-- 
I do have a cause though. It's obscenity. I'm for it.
    - Tom Lehrer

[tap] Rethinking the TAP version Michael G Schwern
Re: [tap] Rethinking the TAP version Aristotle Pagaltzis
Re: [tap] Rethinking the TAP version Michael G Schwern
Re: [tap] Rethinking the TAP version Eric Wilhelm
Re: [tap] Rethinking the TAP version Aristotle Pagaltzis