From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6988 invoked by alias); 30 Aug 2004 10:16:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6979 invoked from network); 30 Aug 2004 10:16:15 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sourceware.org with SMTP; 30 Aug 2004 10:16:15 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i7UAEYbR011407 for ; Mon, 30 Aug 2004 12:14:34 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id i7UAEXw0011406; Mon, 30 Aug 2004 12:14:33 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: gcc@gcc.gnu.org Subject: Re: Release numbering References: <10408300112.AA22774@vlsi1.ultra.nyu.edu> <20040830012928.GA2387@disaster.jaj.com> <20040830081555.GA8738@disaster.jaj.com> From: Gabriel Dos Reis In-Reply-To: <20040830081555.GA8738@disaster.jaj.com> Organization: Integrable Solutions Date: Mon, 30 Aug 2004 10:22:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg01470.txt.bz2 Phil Edwards writes: Hi, [...] | Here's my point: | | We need to hold the 4.0 label in reserve for Big Incompatible Changes. | Not just "user-visible" ones, although they clearly would play a part. | But any change where the users /must/ know whether 3.x or 4.x is in | use before they (or their tools) can get much farther, /those/ are | what we should wait for before changing the major version. | | The 3.5 code is supposed to be starting to stabilize for release. Now is | clearly not the time to, for example, completely change the formatting | of our diagnostic output. But if we release 3.5 as 4.0, then the Big | Incompatible Changes are going to have to wait until 5.0 to go in. Or 6.0. Or whatever. We never sworn carret diagnostics for 4.0. Not just because we can't implement carret diagnostics now means we should not reject the "huge perturbation" in the next release. "Big Incompatible Changes" can happen several times; we need not wait for all of them happening for 4.0, just like we would not "wait until it is ready" before branching. -- Gaby