Re: [tap] Rethinking the TAP version
Eric Wilhelm <scratchcomputing@gmail.com> Sat, 21 February 2009 06:45 UTC
Return-Path: <scratchcomputing@gmail.com>
X-Original-To: tap@core3.amsl.com
Delivered-To: tap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544CA3A6B5C for <tap@core3.amsl.com>; Fri, 20 Feb 2009 22:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67VexqVT0WfB for <tap@core3.amsl.com>; Fri, 20 Feb 2009 22:45:08 -0800 (PST)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 88DB23A6883 for <tap@ietf.org>; Fri, 20 Feb 2009 22:45:08 -0800 (PST)
Received: by wf-out-1314.google.com with SMTP id 27so1542949wfd.31 for <tap@ietf.org>; Fri, 20 Feb 2009 22:45:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=ScNxbEYNHDsZzIbdklq6ERHfmv04H/BunMNMN1DzkvQ=; b=uQZRylI5plmwN/eLtjzjxIUXJAC1GujrXbU7X8PcnQDK4yiu5HP0QdTNA1hmZXbzMj 7YICHRtGmjOGigGdZ64uM9GP7Pg/qu2XGF4kch1ux6kIYtEpli8wbmX5bowhxrGR4fbf RGMdNf/XrKkmUX2RyvruhQDV7qxy2AFeqoHlM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=SCMXcvNhCGta+x1fawS7e+9PtvQNJATB7p0i1yU/bjC/QCAznr44JDtb8WYnk1UiE+ eRAVpagK7jFe542RSq/x0osSF/c34XgJHvwctFDbhwQuirvCMqEpYLYv/66z6R4mXg9Z GDzIXYHVQal8C9j7np6Ig86dvznViKM6JwQuE=
Received: by 10.142.230.11 with SMTP id c11mr798533wfh.246.1235198723200; Fri, 20 Feb 2009 22:45:23 -0800 (PST)
Received: from gungnir.scratchcomputing.com (pool-71-111-78-159.ptldor.dsl-w.verizon.net [71.111.78.159]) by mx.google.com with ESMTPS id 30sm8723329wfc.44.2009.02.20.22.45.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 22:45:22 -0800 (PST)
From: Eric Wilhelm <scratchcomputing@gmail.com>
To: tap@ietf.org
Date: Fri, 20 Feb 2009 22:45:19 -0800
User-Agent: KMail/1.9.5
References: <499DF1D6.9020009@pobox.com> <20090220114947.GB16059@klangraum.plasmasturm.org> <499F3BA3.5010604@pobox.com>
In-Reply-To: <499F3BA3.5010604@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200902202245.20010.scratchcomputing@gmail.com>
Subject: Re: [tap] Rethinking the TAP version
X-BeenThere: tap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Test Anything Protocol WG discussions <tap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tap>, <mailto:tap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tap>
List-Post: <mailto:tap@ietf.org>
List-Help: <mailto:tap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tap>, <mailto:tap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2009 06:45:09 -0000
# from Michael G Schwern
# on Friday 20 February 2009 15:24:
>I get what you're saying. The problem is we have no namespace.
That's exactly what I was thinking. Yes a major version bump is
basically a new protocol, but you still need some way to indicate it.
I'm in favor of a $major.$minor version scheme. You could choose to
name the major (incompatible) bumps after cartoon characters or types
of fish, but numbers have a nice sequence.
--Eric
--
"It is impossible to make anything foolproof because fools are so
ingenious."
--Murphy's Second Corollary
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
- [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