Re: [tap] Rethinking the TAP version

[Aristotle Pagaltzis <[e-mail]>]

* 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.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>