Re: [tap] Rethinking the TAP version

Aristotle Pagaltzis <pagaltzis@gmx.de> Mon, 23 February 2009 09:30 UTC

Date: Mon, 23 Feb 2009 10:30:35 +0100
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
To: tap@ietf.org
Message-ID: <20090223093035.GA11875@klangraum.plasmasturm.org>
Mail-Followup-To: tap@ietf.org
References: <499DF1D6.9020009@pobox.com> <20090220114947.GB16059@klangraum.plasmasturm.org> <499F3BA3.5010604@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <499F3BA3.5010604@pobox.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [tap] Rethinking the TAP version
Precedence: list

* Michael G Schwern <schwern@pobox.com> [2009-02-21 00:25]:
> 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".

Ugh. Yeah.

A corollary is that pre-v13 consumers are a problem no matter
what, as well.

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

How about `TAP 1 version 12` then? Because the reason I brought
this up in the first place is that I’d like the notation to
convey that we expect the basic protocol to almost never change.
Using a $major.$minor versioning scheme seems to suggest that we
expect the major version to change relatively frequently. The
notation should be designed for psychological friction against
the idea of willy-nilly change and over-generalisation in
consumers.

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

[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