From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 18:42:31 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 174BD16A47B for ; Fri, 16 Jun 2006 18:42:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 350E243D49 for ; Fri, 16 Jun 2006 18:42:30 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 2069 invoked by uid 399); 16 Jun 2006 18:42:29 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Jun 2006 18:42:29 -0000 Message-ID: <4492FB95.9050606@FreeBSD.org> Date: Fri, 16 Jun 2006 11:42:29 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Robert Watson References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> In-Reply-To: <20060616102458.N742@fledge.watson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 18:42:31 -0000 I'm opposed to this kind of change on principle. The issue of subtle but incompatible changes to the API within a major release branch has come up before as one of the reasons that vendors find it difficult/uninteresting to support FreeBSD. With our new shorter release cycles, I think we need to draw a line in the sand and declare unambiguously that the APIs will NOT change within a release, and then live (and learn) with the consequences. If these (or any other) changes become so compelling that we feel the userbase needs to have them ASAP, I would suggest that this would be justification to move up the release cycle for 7.x, not to break faith in 6.x. Doug -- This .signature sanitized for your protection