From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 28 Jan 2013 19:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org X-Debbugs-Original-To: Automake List , bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.13594025967118 (code B ref -1); Mon, 28 Jan 2013 19:50:02 +0000 Received: (at submit) by debbugs.gnu.org; 28 Jan 2013 19:49:56 +0000 Received: from localhost ([127.0.0.1]:52905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzuiJ-0001qk-JS for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44792) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzuiG-0001qb-Gs for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tzuhl-0004ko-Ps for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:25 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:59722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tzuhl-0004ke-NK for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tzuhk-000772-3W for bug-automake@gnu.org; Mon, 28 Jan 2013 14:49:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tzuhi-0004j7-9P for bug-automake@gnu.org; Mon, 28 Jan 2013 14:49:19 -0500 Received: from mail-bk0-f43.google.com ([209.85.214.43]:51068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tzuhd-0004i5-EO; Mon, 28 Jan 2013 14:49:13 -0500 Received: by mail-bk0-f43.google.com with SMTP id jm19so1128469bkc.30 for ; Mon, 28 Jan 2013 11:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; bh=8nJoyeA/5FBIa4SiDDrQ6CdzT973tprxeNY55EDkvYw=; b=sZB4yFvSRPHR/nUxHQuSviJ7h1hYYI8vobRLsq9ViDo/yiSAH3T2bD0fwGNGBS7v8U g/efix3xjoVoTi7t7pA2iwNVI9njyaMGPIsc3Vbaxw+QxK2s7UObVskMZEEZ56L77MPE Vd7ZWtR+HtLRGH5oVe6S3lc180f7P/bdIhdzSuc+QaOPTA8/uCFGoA863FNeFyOuJRLS ObB4HVt/Xp2nc8p6w9bndbveYkQJEwu9Fs1uWWO6f+/mju6MUpigpPStDijis454WvVt mo5HqJBcYIhGb83uC+ZTXQ9qDTkrYg2oThLFjrIr9B5SiCkTHgcbTpeirfaHN6Z5MjKM U1Rw== X-Received: by 10.204.132.68 with SMTP id a4mr1944374bkt.42.1359402551836; Mon, 28 Jan 2013 11:49:11 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id hc16sm7373213bkc.2.2013.01.28.11.49.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 11:49:10 -0800 (PST) Message-ID: <5106D62B.6070007@gmail.com> Date: Mon, 28 Jan 2013 20:48:59 +0100 From: Stefano Lattarini MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Severity: wishlist Recently, the need of a quick bug-fixing release 1.13.2 has shown some issues with the current branching and versioning scheme of Automake. Let's first see some background, to better understand the situation. Given the typically long time between a major release 1.N and the next one 1.(N+1) (say, 1.11 and 1.12), I had begun, in the last year or so, to introduce some (mostly) safe and backward-compatible but non-trivial changes and enhancements between a minor release 1.N.M and the next one 1.N.(M+1) (say, 1.12.1 and 1.12.2). As an example of such changes, in the NEWS entry for 1.12.2 we have: - Recursive cleaning rules descends into the $(SUBDIRS) in the natural order (as done by the other recursive rules), rather than in the inverse order. They used to do that in order to work a round a limitation in an older implementation of the automatic dependency tracking support, but that limitation had been lifted years ago already, when the automatic dependency tracking based on side-effects of compilation had been introduced. And in the NEWS entry for 1.11.3 we have: - For programs and libraries, automake now detects EXTRA_foo_DEPENDENCIES and adds them to the normal list of dependencies, but without overwriting the foo_DEPENDENCIES variable, which is normally computed by automake. - "make dist" can now create lzip-compressed tarballs. This approach has however shown several drawbacks since its introduction: * Such changes might be not trivial, and their correct implementation and testing can leave the maint branch in a non-safely-releasable state, thus complicating the cut of a urgent bug-fixing release. * Given the current maint/master branching scheme, the sudden need of such a release forces us to mess with the planned version numbers and the branching setup, since we might not be able to cut such a release from maint (as that might already contain some changes we consider inappropriate for a mere bug-fixing release). * Some bug-fixes (especially for for old bugs) or code clean-ups and refactorings (especially for old or complex code) might cause backward-incompatible changes in the semantics of some corner-case behaviours; that can unpleasantly surprise users who are thinking they are getting only basic bug-fixes, and get instead bitten by an unexpected behavioural change. Such users might rightfully complain that, while they approve the change and are well ready to adapt their packages to it, they don't expect to be forced to do so when upgrading to a mere minor release. See for example: http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html So I propose the following change in the Automake versioning scheme: * Major releases should actually have the major version number bumped. That is, the next major Automake version will be 2.0, rather than 1.14; and the major version after that will be 3.0; and so on. After all, there is no shortage of integer numbers to use :-) Such major releases can introduce backward-incompatibilities (albeit such incompatibilities should be announced well in advance, and a smooth transition plan prepared for them), and try more risking and daring refactorings. * Minor releases have the minor version number bumped (1.13 -> 1.14 -> 1.15 ...), can introduce new "safe" features, do non-trivial but mostly safe code clean-ups, and even add new runtime warnings (rigorously non-fatal); but they shouldn't include any backward incompatible change, nor contain any potentially destabilizing refactoring or sweeping change, nor introduce new features whose implementation might be liable to cause bugs or regressions in existing code. * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing releases; no new features should be added, and ideally, only trivial bugs, recent regressions, or documentation issues should be addressed here. Another plus of this new versioning scheme is that it will allow different minor releases, even with the same major version, to co-exist on the same system (that's because the $(APIVERSION) variable will get bumped with each minor version now). I also propose the following change to the branching scheme currently implemented in the Automake Git repository: * The 'maint' branch will be reserved to cut of the next micro release; so it will just see fixes for regressions, trivial bugs, or documentation issues, and no "active" development whatsoever. * The 'master' branch will be where the development of the next minor release will take place; that is, a sort of "middle-ground" between the roles so far fulfilled by the 'maint' and 'master' branches in the current branching scheme. * The (new) 'next' branch will be reserved for the development of the next major release; it will basically take over the rule that is currently fulfilled by the 'master' branch. * 'maint' will be kept regularly merged into 'master', and 'master' into 'next' (and 'next' into the 'ng/master', which is where the Automake-NG codebase currently live). * Feature branches should typically be based off of 'master', and we can decide later whether to eventually merge them into 'master' or into 'next'. * None of 'maint', 'master' and 'next' should be rewindable. If you agree with my proposal, I think the new schemes could be implemented right after the 1.13.2 release; so that the planned Automake 1.13.3 will be released as 1.14, and the planned Automake 1.14 will be released as Automake 2.0. And of course, we'll have to publicize the new versioning scheme ASAP, and with quite high visibility. I propose the following avenues: - A news item in the savannah AUtomake page; - A message to autotools-announce; - An entry in the NEWS file of 1.13.2. - ??? (suggestions welcome) -*-*- Feedback, opinions, objections? Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Jack Kelly Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 29 Jan 2013 01:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: 13578@debbugs.gnu.org, automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13594230459303 (code B ref 13578); Tue, 29 Jan 2013 01:31:02 +0000 Received: (at 13578) by debbugs.gnu.org; 29 Jan 2013 01:30:45 +0000 Received: from localhost ([127.0.0.1]:53178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0028-0002Pz-FJ for submit@debbugs.gnu.org; Mon, 28 Jan 2013 20:30:45 -0500 Received: from mail-pa0-f49.google.com ([209.85.220.49]:58389) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0026-0002Pp-HH for 13578@debbugs.gnu.org; Mon, 28 Jan 2013 20:30:43 -0500 Received: by mail-pa0-f49.google.com with SMTP id bi1so43961pad.22 for <13578@debbugs.gnu.org>; Mon, 28 Jan 2013 17:30:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type:x-gm-message-state; bh=at9hLa8AqOSH9lG0XYhfQEDIJ5r8ifG5kyhTeRc5Ixs=; b=BzMnr7vroio0wMsLzjmawdCEulvsrWLW7eMNiCZfMzVxbXLxNCWiJeE88Cpv5FaDjM zrPEJsvJD6Si7f/jPs5n268TUvpO8AUA6fyg9Om8G1enBcss+4IRfxV0WM1JBvEOg/8U h4kVGo8zcyE1tPWIQ31hwcXgbSxE8UcIT5Lwr+XsN5K+vzKY5I1esRbJR1LwwZjzuvcM E88lCyjv7RN7K4PPutQPGTycZfjDvjTVJBxNEG8j3fZOnqUHAsAoeIx0P0h3uAaXcV0A Y1kDD2fHHcH7nuPfs3ONw1idememL9aP8E9OrBO6dOpD+P2Nco7SzxClH7LtMHlQdyNW fLCg== X-Received: by 10.68.200.228 with SMTP id jv4mr41660392pbc.139.1359423013703; Mon, 28 Jan 2013 17:30:13 -0800 (PST) Received: from handybilly ([125.253.98.148]) by mx.google.com with ESMTPS id p9sm7774054pao.29.2013.01.28.17.30.10 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 28 Jan 2013 17:30:12 -0800 (PST) From: Jack Kelly References: <5106D62B.6070007@gmail.com> Date: Tue, 29 Jan 2013 12:30:04 +1100 In-Reply-To: <5106D62B.6070007@gmail.com> (Stefano Lattarini's message of "Mon, 28 Jan 2013 20:48:59 +0100") Message-ID: <87d2woojxf.fsf@jackkelly.name> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Gm-Message-State: ALoCoQnZAj727WRKEthOMs3R0CH9PIlbujd068ch3HrxNeN3mliENwdA3Y1/0jBR1MT58XzdXLPe X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Stefano Lattarini writes: > So I propose the following change in the Automake versioning scheme: > > * Major releases should actually have the major version number bumped. > That is, the next major Automake version will be 2.0, rather than > 1.14; and the major version after that will be 3.0; and so on. > After all, there is no shortage of integer numbers to use :-) > Such major releases can introduce backward-incompatibilities (albeit > such incompatibilities should be announced well in advance, and a > smooth transition plan prepared for them), and try more risking > and daring refactorings. > > * Minor releases have the minor version number bumped (1.13 -> 1.14 > -> 1.15 ...), can introduce new "safe" features, do non-trivial > but mostly safe code clean-ups, and even add new runtime warnings > (rigorously non-fatal); but they shouldn't include any backward > incompatible change, nor contain any potentially destabilizing > refactoring or sweeping change, nor introduce new features whose > implementation might be liable to cause bugs or regressions in > existing code. > > * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing > releases; no new features should be added, and ideally, only > trivial bugs, recent regressions, or documentation issues should > be addressed here. This sounds quite resonable to me, but is there anyone who is relying on automake versions taking the form 1.x.y? It might be worth reaching out to the distro packagers, just in case. -- Jack From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Thien-Thi Nguyen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 29 Jan 2013 07:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: 13578@debbugs.gnu.org, automake@gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org, Automake List Received: via spool by submit@debbugs.gnu.org id=B.13594433227186 (code B ref -1); Tue, 29 Jan 2013 07:09:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 Jan 2013 07:08:42 +0000 Received: from localhost ([127.0.0.1]:53543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U05JA-0001rp-Nt for submit@debbugs.gnu.org; Tue, 29 Jan 2013 02:08:42 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34740) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U05J7-0001ri-TD for submit@debbugs.gnu.org; Tue, 29 Jan 2013 02:08:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U05Id-0006wp-Ep for submit@debbugs.gnu.org; Tue, 29 Jan 2013 02:08:08 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:41024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U05Id-0006wl-BH for submit@debbugs.gnu.org; Tue, 29 Jan 2013 02:08:07 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U05Ib-0005uk-TL for bug-automake@gnu.org; Tue, 29 Jan 2013 02:08:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U05Ia-0006uk-VI for bug-automake@gnu.org; Tue, 29 Jan 2013 02:08:05 -0500 Received: from smtp209.alice.it ([82.57.200.105]:58487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U05IW-0006nb-H7; Tue, 29 Jan 2013 02:08:00 -0500 Received: from zigzag.favinet (79.10.157.178) by smtp209.alice.it (8.6.060.12) id 50FE8EA601642F97; Tue, 29 Jan 2013 08:07:53 +0100 Received: from ttn by zigzag.favinet with local (Exim 4.72) (envelope-from ) id 1U05K7-0002Jv-9J; Tue, 29 Jan 2013 08:09:39 +0100 From: Thien-Thi Nguyen References: <5106D62B.6070007@gmail.com> Date: Tue, 29 Jan 2013 08:09:28 +0100 In-Reply-To: <5106D62B.6070007@gmail.com> (Stefano Lattarini's message of "Mon, 28 Jan 2013 20:48:59 +0100") Message-ID: <87ham0mpnb.fsf@zigzag.favinet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.5 (-----) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable () Stefano Lattarini () Mon, 28 Jan 2013 20:48:59 +0100 So I propose the following change in the Automake versioning scheme: [...] Sounds good. Going further, you could maybe define notation (described in HACKING) for categories of changes (backward-{in}compatible, etc) and methodically use them in the ChangeLog entries. This would be both informative to the user, and helpful to prevent mistakes (by casual contributors :-D). I also propose the following change to the branching scheme currently implemented in the Automake Git repository: [...] These details should also be explained in HACKING. to publicize the new versioning scheme - ??? (suggestions welcome) Maybe cut a release that changes only the version number? Personally i would find that to be not particularly useful, but others might welcome the explicitness. =2D-=20 Thien-Thi Nguyen ..................................... GPG key: 4C807502 . NB: ttn at glug dot org is not me . . (and has not been since 2007 or so) . . ACCEPT NO SUBSTITUTES . ........... please send technical questions to mailing lists ........... --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlEHda0ACgkQZwMiJEyAdQJDNQCgl5ZFBYOxXDVGn6RYH+5EMRNw iUgAn1qQgj+VSFtn36PeVADWSZ3rykWu =fA4S -----END PGP SIGNATURE----- --=-=-=-- From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Peter Johansson Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 29 Jan 2013 12:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: 13578@debbugs.gnu.org, automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13594619762266 (code B ref 13578); Tue, 29 Jan 2013 12:20:02 +0000 Received: (at 13578) by debbugs.gnu.org; 29 Jan 2013 12:19:36 +0000 Received: from localhost ([127.0.0.1]:53792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0AA4-0000aV-8E for submit@debbugs.gnu.org; Tue, 29 Jan 2013 07:19:36 -0500 Received: from mail-pb0-f53.google.com ([209.85.160.53]:59264) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0AA1-0000aH-Hx for 13578@debbugs.gnu.org; Tue, 29 Jan 2013 07:19:34 -0500 Received: by mail-pb0-f53.google.com with SMTP id un1so250939pbc.12 for <13578@debbugs.gnu.org>; Tue, 29 Jan 2013 04:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=38AKMqX+SlkNdrVD5dE1tMs5HrC1tDmJPGXpE0pouDU=; b=GBRiasmy99AnTfangDC2ZDfN2WtQFegqyLI66C88DYH9JRKtQ8i5wGHiUl77Xzs71g CPnGATttjBgkngSyJ0QS9b5mzSDRqa90yNAagpwleCQ5XOvoB+6dZP/LpaFnUd0jIlp+ Vmm6OsTEJJB0ScYTEG+FoAZaz3xWs2F02V2U14ayDwkPbhsU36kUx+AWQ/gELYvU/J2f TtYKczGe8ge86qIX2PzqTFHfy8Oom45YseSDdALmRINadVTwqW0rhgFyByVTviq69wUU O5sh+96x58ljrsCyWdPPQBtDD5jqi0Hu7BRTnTSNMY5hmzJubb3MOiq+UHYvYHT8rJyN pA1w== X-Received: by 10.68.222.196 with SMTP id qo4mr1746488pbc.140.1359461942069; Tue, 29 Jan 2013 04:19:02 -0800 (PST) Received: from limpar.local (124-170-81-6.dyn.iinet.net.au. [124.170.81.6]) by mx.google.com with ESMTPS id rv8sm8318786pbc.27.2013.01.29.04.18.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 04:19:00 -0800 (PST) Message-ID: <5107BE2C.7020309@gmail.com> Date: Tue, 29 Jan 2013 22:18:52 +1000 From: Peter Johansson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> In-Reply-To: <5106D62B.6070007@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Stefano, On 1/29/13 5:48 AM, Stefano Lattarini wrote: > Severity: wishlist > > Recently, the need of a quick bug-fixing release 1.13.2 has shown some > issues with the current branching and versioning scheme of Automake. > > Let's first see some background, to better understand the situation. > > Given the typically long time between a major release 1.N and the next > one 1.(N+1) (say, 1.11 and 1.12), I had begun, in the last year or so, > to introduce some (mostly) safe and backward-compatible but non-trivial > changes and enhancements between a minor release 1.N.M and the next one > 1.N.(M+1) (say, 1.12.1 and 1.12.2). > > As an example of such changes, in the NEWS entry for 1.12.2 we have: > > - Recursive cleaning rules descends into the $(SUBDIRS) in the natural > order (as done by the other recursive rules), rather than in the > inverse order. They used to do that in order to work a round a > limitation in an older implementation of the automatic dependency > tracking support, but that limitation had been lifted years ago > already, when the automatic dependency tracking based on side-effects > of compilation had been introduced. > > And in the NEWS entry for 1.11.3 we have: > > - For programs and libraries, automake now detects EXTRA_foo_DEPENDENCIES > and adds them to the normal list of dependencies, but without > overwriting the foo_DEPENDENCIES variable, which is normally computed > by automake. > > - "make dist" can now create lzip-compressed tarballs. > > This approach has however shown several drawbacks since its introduction: > > * Such changes might be not trivial, and their correct implementation > and testing can leave the maint branch in a non-safely-releasable > state, thus complicating the cut of a urgent bug-fixing release. > > * Given the current maint/master branching scheme, the sudden need > of such a release forces us to mess with the planned version numbers > and the branching setup, since we might not be able to cut such > a release from maint (as that might already contain some changes we > consider inappropriate for a mere bug-fixing release). > > * Some bug-fixes (especially for for old bugs) or code clean-ups and > refactorings (especially for old or complex code) might cause > backward-incompatible changes in the semantics of some corner-case > behaviours; that can unpleasantly surprise users who are thinking > they are getting only basic bug-fixes, and get instead bitten by an > unexpected behavioural change. Such users might rightfully complain > that, while they approve the change and are well ready to adapt > their packages to it, they don't expect to be forced to do so when > upgrading to a mere minor release. See for example: > http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html > > So I propose the following change in the Automake versioning scheme: > > * Major releases should actually have the major version number bumped. > That is, the next major Automake version will be 2.0, rather than > 1.14; and the major version after that will be 3.0; and so on. > After all, there is no shortage of integer numbers to use :-) > Such major releases can introduce backward-incompatibilities (albeit > such incompatibilities should be announced well in advance, and a > smooth transition plan prepared for them), and try more risking > and daring refactorings. > > * Minor releases have the minor version number bumped (1.13 -> 1.14 > -> 1.15 ...), can introduce new "safe" features, do non-trivial > but mostly safe code clean-ups, and even add new runtime warnings > (rigorously non-fatal); but they shouldn't include any backward > incompatible change, nor contain any potentially destabilizing > refactoring or sweeping change, nor introduce new features whose > implementation might be liable to cause bugs or regressions in > existing code. Will it still be linear, or do you expect any 1.x release after 2.0? > * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing > releases; no new features should be added, and ideally, only > trivial bugs, recent regressions, or documentation issues should > be addressed here. > IMVHO, this is how it always has been, except the last year or so. See for example release of Automake 1.10.2, which only fixed a couple of bugs. Change of behaviour (like recursive cleaning mentioned above) or optimizing the code never belong in a micro release. I'm glad you clary this. > Another plus of this new versioning scheme is that it will allow > different minor releases, even with the same major version, to > co-exist on the same system (that's because the $(APIVERSION) > variable will get bumped with each minor version now). Why is that a plus? What is the use case when I want to keep on using Automake 2.1 after I have installed Automake 2.2? Assuming 2.2 is 100% backward compatible I cannot see the use case. What am I missing? In general I like the clarification, but I wonder what the expected frequency of major/minor releases are. If you expect more major releases than minor releases, the future series of versions would look something like: 2.0 2.0.1 2.0.2 2.1 3.0 3.0.1 4.0 ... In other words if the minor releases are rare, the middle digit has no function and it could be removed with no loss: 2.0 -> 2.0 2.0.1 -> 2.1 2.0.2 -> 2.2 2.1 -> 3.0 3.0 -> 4.0 3.0.1 -> 4.1 4.0 -> 5.0 or just keep the scheme as is 1.14 1.14.1 1.14.2 1.15 1.16 1.16.1 1.17 Cheers, Peter -- Peter Johansson From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Dave Goodell Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 29 Jan 2013 14:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Peter Johansson Cc: automake@gnu.org, Stefano Lattarini , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.135946939917190 (code B ref 13578); Tue, 29 Jan 2013 14:24:01 +0000 Received: (at 13578) by debbugs.gnu.org; 29 Jan 2013 14:23:19 +0000 Received: from localhost ([127.0.0.1]:53921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0C5l-0004TC-IU for submit@debbugs.gnu.org; Tue, 29 Jan 2013 09:23:18 -0500 Received: from mailhost.anl.gov ([130.202.113.50]:58354) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0C5h-0004T0-EI for 13578@debbugs.gnu.org; Tue, 29 Jan 2013 09:23:15 -0500 Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id BAC5A82; Tue, 29 Jan 2013 08:22:41 -0600 (CST) Received: from zimbra.anl.gov (zimbra.anl.gov [130.202.101.12]) by mailhost.anl.gov (Postfix) with ESMTP id 7593D2F; Tue, 29 Jan 2013 08:22:41 -0600 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.anl.gov (Postfix) with ESMTP id 47A6E1E063; Tue, 29 Jan 2013 08:22:41 -0600 (CST) X-Virus-Scanned: amavisd-new at zimbra.anl.gov Received: from zimbra.anl.gov ([127.0.0.1]) by localhost (zimbra.anl.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGRsxnBHypRW; Tue, 29 Jan 2013 08:22:41 -0600 (CST) Received: from [192.168.0.105] (adsl-76-239-17-138.dsl.emhril.sbcglobal.net [76.239.17.138]) by zimbra.anl.gov (Postfix) with ESMTPSA id DB8B71E05B; Tue, 29 Jan 2013 08:22:40 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Dave Goodell In-Reply-To: <5107BE2C.7020309@gmail.com> Date: Tue, 29 Jan 2013 08:22:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <173D7C33-715E-4EA7-97F2-5EA7295061EE@mcs.anl.gov> References: <5106D62B.6070007@gmail.com> <5107BE2C.7020309@gmail.com> X-Mailer: Apple Mail (2.1283) X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) On Jan 29, 2013, at 6:18 AM CST, Peter Johansson wrote: > On 1/29/13 5:48 AM, Stefano Lattarini wrote: >=20 >> Another plus of this new versioning scheme is that it will allow >> different minor releases, even with the same major version, to >> co-exist on the same system (that's because the $(APIVERSION) >> variable will get bumped with each minor version now). >=20 > Why is that a plus? What is the use case when I want to keep on using = Automake 2.1 after I have installed Automake 2.2? Assuming 2.2 is 100% = backward compatible I cannot see the use case. What am I missing? As a developer, it can be surprisingly difficult to write autotools code = that is portable to several different versions of the autotools. = Sometimes it's convenient to only choose to support some subset of the = autotools version space. Development bandwidth, lack of autotools = expertise, and limited access to testing platforms are all reasonable = reasons that lead to this sort of decision. This in turn causes problems for packagers, since different packages = choose different subsets of the versions space. So as a packager, you = end up either: 1) attempting to patch all of the packages which are incompatible with = your versions of the autotools, which is risky and time-consuming; or 2) juggling several different autotools version tuples. Anything that = makes this difficult quickly can turn into a real PITA. Anything that = makes it easier is always welcome. Putting the developer hat back on, facilitating multiple versions also = makes it easier to test with each of those versions. -Dave From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 29 Jan 2013 18:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Peter Johansson Cc: 13578@debbugs.gnu.org, automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13594843797252 (code B ref 13578); Tue, 29 Jan 2013 18:33:01 +0000 Received: (at 13578) by debbugs.gnu.org; 29 Jan 2013 18:32:59 +0000 Received: from localhost ([127.0.0.1]:54647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0FzO-0001su-IB for submit@debbugs.gnu.org; Tue, 29 Jan 2013 13:32:59 -0500 Received: from mail-ee0-f53.google.com ([74.125.83.53]:50437) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0FzL-0001sm-HJ for 13578@debbugs.gnu.org; Tue, 29 Jan 2013 13:32:57 -0500 Received: by mail-ee0-f53.google.com with SMTP id e53so401246eek.12 for <13578@debbugs.gnu.org>; Tue, 29 Jan 2013 10:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+gGIWRQ7Oe3O0JWUzO1Gy8SlnSuM4Lh1WXEVA2MsJcw=; b=cD8H2QaWhlDPgws/wopC9ryQ3WF5l6NXSxGs01N45xEbha7+JecDB3k5q/Dv3qsMou N/lmAGikGnqT/P6JKIoLezjGyB5F5Wl8FvWEubEYWxoScS+V6cPdZtBGcExZV9soE/EP O+NWXKuZxYCgyxvm0n3Wq1MVNq0/YHdZ7cXJLENN1CyL1oL1yKceih5iFB2YmqX42fD8 HnHSmzB8/AAUOao7inF/8HwsL6Mp1URUzB6xJJaCcP2G9hrlXqpWRd1mJU2dD5VyBfcr XRi1hU+AoEnroA1rpW0VO6ECiRmimCBYunTM7w9/AUtz48FEbFiZcDGmEWcvaRhb2PrH 3Q5A== X-Received: by 10.14.173.65 with SMTP id u41mr5883282eel.13.1359484342516; Tue, 29 Jan 2013 10:32:22 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id g2sm21347391eep.16.2013.01.29.10.32.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 10:32:21 -0800 (PST) Message-ID: <510815B3.8090909@gmail.com> Date: Tue, 29 Jan 2013 19:32:19 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <5107BE2C.7020309@gmail.com> In-Reply-To: <5107BE2C.7020309@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 01/29/2013 01:18 PM, Peter Johansson wrote: > Hi Stefano, > Hi Peter and everybody, and thanks for the feedback. > [SNIP] > > Stefano Lattarini wrote: > >> So I propose the following change in the Automake versioning scheme: >> >> * Major releases should actually have the major version number bumped. >> That is, the next major Automake version will be 2.0, rather than >> 1.14; and the major version after that will be 3.0; and so on. >> After all, there is no shortage of integer numbers to use :-) >> Such major releases can introduce backward-incompatibilities (albeit >> such incompatibilities should be announced well in advance, and a >> smooth transition plan prepared for them), and try more risking >> and daring refactorings. >> >> * Minor releases have the minor version number bumped (1.13 -> 1.14 >> -> 1.15 ...), can introduce new "safe" features, do non-trivial >> but mostly safe code clean-ups, and even add new runtime warnings >> (rigorously non-fatal); but they shouldn't include any backward >> incompatible change, nor contain any potentially destabilizing >> refactoring or sweeping change, nor introduce new features whose >> implementation might be liable to cause bugs or regressions in >> existing code. > > Will it still be linear, or do you expect any 1.x release after 2.0? > Ideally, it should still be linear. We could easily create an 'old-release' branch from the last 1.x release, and backport bug fixes implemented in the 2.x series there; but I'd rather not do so, unless there is a strong demand from the user base. >> * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing >> releases; no new features should be added, and ideally, only >> trivial bugs, recent regressions, or documentation issues should >> be addressed here. >> > IMVHO, this is how it always has been, except the last year or so. > Yes, my bad there, sorry. This is an attempt to remedy to it, and improve the release scheme a little in the process. > See for example release of Automake 1.10.2, which only fixed a couple > of bugs. Change of behaviour (like recursive cleaning mentioned above) > or optimizing the code never belong in a micro release. I'm glad you > clarify this. > I should have probably done it earlier. Well, better late then never. >> Another plus of this new versioning scheme is that it will allow >> different minor releases, even with the same major version, to >> co-exist on the same system (that's because the $(APIVERSION) >> variable will get bumped with each minor version now). > > Why is that a plus? What is the use case when I want to keep on > using Automake 2.1 after I have installed Automake 2.2? > The fact that a change like the "recursive cleaning" mentioned above might have broken, in 2.2, some tricky usages in your makefiles, usages that used to work in 2.1; and you might not want (or be able to) adjust them right away. > Assuming 2.2 is 100% backward compatible > That cannot be guaranteed, as some bug fixes might break some corner-case usages (especially when bugs were being used as features, through no fault or abuse of the user; see for example ); this is why I think this kind of bug-fixes should go in a new minor release, rather than in a micro release. Moreover, a new minor release could add new (non-fatal) warnings that were not present in the previous one, and this too amount to a small backward incompatibility (or not so small, if you are making the mistake of having '-Werror' in AUTOMAKE_OPTIONS). > I cannot see the use case. What am I missing? > Is the answer above enough? Anyway, notice that the allowed co-existence of minor releases would only be a side effect of the proposed change, and not a motivating factor. So even if it turns out to be mostly useless, that is no problem. > In general I like the clarification, but I wonder what the expected > frequency of major/minor releases are. > Ideally, we should aim for a major release once a year (or longer, even), a minor one every two or three months, and a micro one whenever needed. > If you expect more major releases than minor releases, > I don't (albeit this concern of yours is something to be kept in mind). > the future series of versions would look something like: > > 2.0 > 2.0.1 > 2.0.2 > 2.1 > 3.0 > 3.0.1 > 4.0 > ... > In other words if the minor releases are rare, the middle digit > has no function and it could be removed with no loss: > > 2.0 -> 2.0 > 2.0.1 -> 2.1 > 2.0.2 -> 2.2 > 2.1 -> 3.0 > 3.0 -> 4.0 > 3.0.1 -> 4.1 > 4.0 -> 5.0 > The whole point of this proposal is that minor releases (not merely bug-fixing ones) have been proving to be quite common recently :-) > or just keep the scheme as is > 1.14 > 1.14.1 > 1.14.2 > 1.15 > 1.16 > 1.16.1 > 1.17 > > > Cheers, > Peter > Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 29 Jan 2013 18:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Thien-Thi Nguyen Cc: 13578@debbugs.gnu.org, automake@gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org, Automake List Received: via spool by submit@debbugs.gnu.org id=B.13594851388388 (code B ref -1); Tue, 29 Jan 2013 18:46:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 Jan 2013 18:45:38 +0000 Received: from localhost ([127.0.0.1]:54657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0GBd-0002BE-3X for submit@debbugs.gnu.org; Tue, 29 Jan 2013 13:45:37 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57755) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0GBY-0002B5-Cv for submit@debbugs.gnu.org; Tue, 29 Jan 2013 13:45:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0GB0-00049A-RG for submit@debbugs.gnu.org; Tue, 29 Jan 2013 13:45:00 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:51354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0GB0-00048o-Ny for submit@debbugs.gnu.org; Tue, 29 Jan 2013 13:44:58 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0GAz-00051p-Qm for bug-automake@gnu.org; Tue, 29 Jan 2013 13:44:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0GAy-00046K-SE for bug-automake@gnu.org; Tue, 29 Jan 2013 13:44:57 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:53971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0GAu-00045d-7D; Tue, 29 Jan 2013 13:44:52 -0500 Received: by mail-ee0-f44.google.com with SMTP id l10so409676eei.17 for ; Tue, 29 Jan 2013 10:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qNI+5Irt8FNUXnnd2TJQQRcBSJ05jID/cbC48XkVL3k=; b=RDbMw0UigcfE0ERVOxiOHq/ECaJWVKBESNu0Vu2Tsab+nMwV6iOkrupLTMDEyPIdxS eBKf69E9tsxnOJ+IuHJS2uhExiJGs3sl6KKbA7lULv55Tp6Gw80Y1aVNzmQuPp4Ulfoa lJZ8KNwWOwP1py0zfdQ+DnXJqVmwaRQ9Rr7bZYx2XZr2S6qBKxYLdPII7DOGTCIMF/oe RWyGBDlgyw4icqwTCGk6EUkAQmzgiP8/t0aJXWwhoGr0PfRFfzsKgiVXXGeFF6kl+h1I sp28y3YjQozwRMANNcZH61+qOC2vJ+nIX71Yqyd49YiacbRmTbQf7qsM50dh1qrOjkT/ V/aQ== X-Received: by 10.14.216.70 with SMTP id f46mr6057669eep.12.1359485091183; Tue, 29 Jan 2013 10:44:51 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id t4sm21335105eel.0.2013.01.29.10.44.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 10:44:50 -0800 (PST) Message-ID: <510818A0.5060803@gmail.com> Date: Tue, 29 Jan 2013 19:44:48 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <87ham0mpnb.fsf@zigzag.favinet> In-Reply-To: <87ham0mpnb.fsf@zigzag.favinet> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) On 01/29/2013 08:09 AM, Thien-Thi Nguyen wrote: > () Stefano Lattarini > () Mon, 28 Jan 2013 20:48:59 +0100 > > So I propose the following change in the Automake versioning scheme: > [...] > > Sounds good. Going further, you could maybe define notation (described > in HACKING) for categories of changes (backward-{in}compatible, etc) > Fully agreed; and abridged version of this proposal is to land in HACKING soon(ish). > and methodically use them in the ChangeLog entries. > This would be overkill IMVHO. > This would be both informative to the user, and helpful to prevent > mistakes (by casual contributors :-D). > > I also propose the following change to the branching scheme currently > implemented in the Automake Git repository: > [...] > > These details should also be explained in HACKING. > Again, +1 > to publicize the new versioning scheme > > - ??? (suggestions welcome) > > Maybe cut a release that changes only the version number? > > Personally I would find that to be not particularly useful, but others might > welcome the explicitness. > Sounds overkill, and some people might even be annoyed by this ("you made me upgrade my installation only to bump the version number ?!?"). I'd rather avoid that. Let's hope a clear NEWS entry in 1.13.2 will be enough to catch the eyes of enough people. Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Daniel Herring Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 30 Jan 2013 03:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org X-Debbugs-Original-To: Automake List , bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.135951669923813 (code B ref -1); Wed, 30 Jan 2013 03:32:02 +0000 Received: (at submit) by debbugs.gnu.org; 30 Jan 2013 03:31:39 +0000 Received: from localhost ([127.0.0.1]:54954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0OOe-0006By-Hg for submit@debbugs.gnu.org; Tue, 29 Jan 2013 22:31:38 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43502) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0OOa-0006Bn-7n for submit@debbugs.gnu.org; Tue, 29 Jan 2013 22:31:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0OO0-0005T6-FF for submit@debbugs.gnu.org; Tue, 29 Jan 2013 22:30:57 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, T_DKIM_INVALID,USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:41915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0OO0-0005Sz-81 for submit@debbugs.gnu.org; Tue, 29 Jan 2013 22:30:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0ONy-0002n8-PP for bug-automake@gnu.org; Tue, 29 Jan 2013 22:30:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0ONx-0005Sg-Fw for bug-automake@gnu.org; Tue, 29 Jan 2013 22:30:54 -0500 Received: from caiajhbdcbhh.dreamhost.com ([208.97.132.177]:52927 helo=homiemail-a15.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0ONu-0005SD-KJ; Tue, 29 Jan 2013 22:30:50 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 267A876C06F; Tue, 29 Jan 2013 19:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tentpost.com; h=date:from :to:subject:in-reply-to:message-id:references:mime-version: content-type; s=tentpost.com; bh=VFBSMBbHjImEKmeSvW7OMfxANfg=; b=gMSbUqYiQ297RXVvvCwyaTqaEmalNX0zpkR47sYVJ1CibJ40emHYpx0kKs7uS Dm3QSeatZbn70/CnUDuxaCk24ZoAq2tpidRRpAyUBU2IFvifV19HYUGVtOlsgA5l WwcP8e/ePYDQ4TIWxelSwEJN3cXP1HLwYJEGxhMPcFljhM= Received: from strider2.home (pool-173-48-243-37.bstnma.fios.verizon.net [173.48.243.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dherring@tentpost.com) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id C002876C06E; Tue, 29 Jan 2013 19:30:48 -0800 (PST) Date: Tue, 29 Jan 2013 22:30:47 -0500 (EST) From: Daniel Herring X-X-Sender: nuntius@strider2.example.org In-Reply-To: <5106D62B.6070007@gmail.com> Message-ID: References: <5106D62B.6070007@gmail.com> User-Agent: Alpine 2.02 (LNX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) On Mon, 28 Jan 2013, Stefano Lattarini wrote: > Feedback, opinions, objections? There was a lot to read, and I confess to not giving it full justice. Others have already extolled the virtues of backwards compatibility. Regarding some "why" questions, here's the manual entry on how versioning is used today. http://www.gnu.org/software/automake/manual/html_node/API-Versioning.html As far as I can tell, the current proposal boils down to "bump the major version more often". That can work, but I'm not quite sold on it. I like when a major bump means "wake up and reread the docs before upgrading" and minor bumps mean "upgrade casually". (and aggregate changes to minimize major bumps and make them more worthwhile) Here are a couple "standards" for versioning. http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html http://semver.org/ The general principle being A.B.C decodes to something easy like A = new API, breaking changes requiring human intervention B = same API, maybe with added options, mostly just recompile C = just bugfixes, documentation tweaks, packaging, etc. For example, a deprecation warning bumps B, but actually removing the deprecated functionality bumps A. As for branching, if every release is tagged, and you want to apply a bugfix to release A.B.C, why not just create a maint-A.B branch or the like? Delay creating branches until they are needed. I wasn't seeing the need for the complex branching details. I agree its nearing time for a "2.0" release; there has been talk of removing several now-deprecated functions and making other major changes (e.g. parallel testing). Would it be possible to start collecting these into a preview/beta release and leave the "1.0" series with its current API and behaviors? Just a thought. I've done the build system for several projects I'm no longer associated with. It would be nice if the people who inherited them don't have to rework them for a few more years. A major version change (again, small numbers) might motivate distributions to keep both around for a while. Hope that helps, Daniel From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Eric Dorland Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 30 Jan 2013 21:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org X-Debbugs-Original-To: automake@gnu.org, bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.135958027319209 (code B ref -1); Wed, 30 Jan 2013 21:12:01 +0000 Received: (at submit) by debbugs.gnu.org; 30 Jan 2013 21:11:13 +0000 Received: from localhost ([127.0.0.1]:56306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0ew4-0004zl-6v for submit@debbugs.gnu.org; Wed, 30 Jan 2013 16:11:13 -0500 Received: from eggs.gnu.org ([208.118.235.92]:55997) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0et1-0004v8-KA for submit@debbugs.gnu.org; Wed, 30 Jan 2013 16:08:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0esN-0004cq-27 for submit@debbugs.gnu.org; Wed, 30 Jan 2013 16:07:25 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-104.7 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:38561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0esM-0004ci-Uq for submit@debbugs.gnu.org; Wed, 30 Jan 2013 16:07:22 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0esK-0004RD-2w for bug-automake@gnu.org; Wed, 30 Jan 2013 16:07:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0esI-0004b0-IP for bug-automake@gnu.org; Wed, 30 Jan 2013 16:07:20 -0500 Received: from forge.kuroneko.ca ([166.84.136.56]:53494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0esD-0004aA-Vp; Wed, 30 Jan 2013 16:07:14 -0500 Received: from localhost (localhost [127.0.0.1]) by forge.kuroneko.ca (Postfix) with ESMTP id 4DA2582111; Wed, 30 Jan 2013 16:11:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kuroneko.ca; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received:received; s=may09; t= 1359580263; x=1361394663; bh=6/R6JE+vLRHoAZf7dH4edOqX2fXP/WEgW8R ILdcehKw=; b=nkKvCNOmnXGwivzsGjmzr57hpbChbI4jIjkudKXNTqrn8/VX1OK NV3W3HvgqLDtW3/aYUDE2grxH0SQc8KJMdzteB1UQVyKjNjF9V9VMWwVoNElrofj ZNu6Yc1VOVxWirFCglQ8ro40PE+bcUJ94Hz58x5AT0Jh9/HPmYIjuWW0= X-Virus-Scanned: Debian amavisd-new at kuroneko.ca Received: from forge.kuroneko.ca ([127.0.0.1]) by localhost (forge.kuroneko.ca [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 1CT0n9Ld5sG2; Wed, 30 Jan 2013 16:11:03 -0500 (EST) Received: from gambit.kuroneko.ca (gambit.kuroneko.ca [IPv6:2001:470:1f07:ac2:21c:c0ff:fef1:5cf1]) by forge.kuroneko.ca (Postfix) with ESMTPS id 3C7DE82007; Wed, 30 Jan 2013 16:11:03 -0500 (EST) Received: by gambit.kuroneko.ca (Postfix, from userid 1000) id 53DC4700227; Wed, 30 Jan 2013 16:07:09 -0500 (EST) Date: Wed, 30 Jan 2013 16:07:09 -0500 From: Eric Dorland Message-ID: <20130130210709.GX20353@gambit> Mail-Followup-To: automake@gnu.org, bug-automake@gnu.org References: <5106D62B.6070007@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qfesBOB4TKwppX3D" Content-Disposition: inline In-Reply-To: <5106D62B.6070007@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -6.9 (------) X-Mailman-Approved-At: Wed, 30 Jan 2013 16:11:11 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) --qfesBOB4TKwppX3D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Stefano Lattarini (stefano.lattarini@gmail.com) wrote: > Severity: wishlist >=20 > Recently, the need of a quick bug-fixing release 1.13.2 has shown some > issues with the current branching and versioning scheme of Automake. >=20 > Let's first see some background, to better understand the situation. >=20 > Given the typically long time between a major release 1.N and the next > one 1.(N+1) (say, 1.11 and 1.12), I had begun, in the last year or so, > to introduce some (mostly) safe and backward-compatible but non-trivial > changes and enhancements between a minor release 1.N.M and the next one > 1.N.(M+1) (say, 1.12.1 and 1.12.2). >=20 > As an example of such changes, in the NEWS entry for 1.12.2 we have: >=20 > - Recursive cleaning rules descends into the $(SUBDIRS) in the natural > order (as done by the other recursive rules), rather than in the > inverse order. They used to do that in order to work a round a > limitation in an older implementation of the automatic dependency > tracking support, but that limitation had been lifted years ago > already, when the automatic dependency tracking based on side-effects > of compilation had been introduced. >=20 > And in the NEWS entry for 1.11.3 we have: >=20 > - For programs and libraries, automake now detects EXTRA_foo_DEPENDENCI= ES > and adds them to the normal list of dependencies, but without > overwriting the foo_DEPENDENCIES variable, which is normally computed > by automake. >=20 > - "make dist" can now create lzip-compressed tarballs. >=20 > This approach has however shown several drawbacks since its introduction: >=20 > * Such changes might be not trivial, and their correct implementation > and testing can leave the maint branch in a non-safely-releasable > state, thus complicating the cut of a urgent bug-fixing release. >=20 > * Given the current maint/master branching scheme, the sudden need > of such a release forces us to mess with the planned version numbers > and the branching setup, since we might not be able to cut such > a release from maint (as that might already contain some changes we > consider inappropriate for a mere bug-fixing release). >=20 > * Some bug-fixes (especially for for old bugs) or code clean-ups and > refactorings (especially for old or complex code) might cause > backward-incompatible changes in the semantics of some corner-case > behaviours; that can unpleasantly surprise users who are thinking > they are getting only basic bug-fixes, and get instead bitten by an > unexpected behavioural change. Such users might rightfully complain > that, while they approve the change and are well ready to adapt > their packages to it, they don't expect to be forced to do so when > upgrading to a mere minor release. See for example: > http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html >=20 > So I propose the following change in the Automake versioning scheme: >=20 > * Major releases should actually have the major version number bumped. > That is, the next major Automake version will be 2.0, rather than > 1.14; and the major version after that will be 3.0; and so on. > After all, there is no shortage of integer numbers to use :-) > Such major releases can introduce backward-incompatibilities (albeit > such incompatibilities should be announced well in advance, and a > smooth transition plan prepared for them), and try more risking > and daring refactorings. >=20 > * Minor releases have the minor version number bumped (1.13 -> 1.14 > -> 1.15 ...), can introduce new "safe" features, do non-trivial > but mostly safe code clean-ups, and even add new runtime warnings > (rigorously non-fatal); but they shouldn't include any backward > incompatible change, nor contain any potentially destabilizing > refactoring or sweeping change, nor introduce new features whose > implementation might be liable to cause bugs or regressions in > existing code. >=20 > * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing > releases; no new features should be added, and ideally, only > trivial bugs, recent regressions, or documentation issues should > be addressed here. I like it. I think it would mean that Debian could carry less simultaneous automake packages at the same time, ie it would have a separate package per major release and just upgrade that to highest release within that major (eg package automake-2 @ version 2.1.3, automake-3 @ version 3.0.4). > Another plus of this new versioning scheme is that it will allow > different minor releases, even with the same major version, to > co-exist on the same system (that's because the $(APIVERSION) > variable will get bumped with each minor version now). >=20 > I also propose the following change to the branching scheme currently > implemented in the Automake Git repository: >=20 > * The 'maint' branch will be reserved to cut of the next micro > release; so it will just see fixes for regressions, trivial > bugs, or documentation issues, and no "active" development > whatsoever. >=20 > * The 'master' branch will be where the development of the next > minor release will take place; that is, a sort of "middle-ground" > between the roles so far fulfilled by the 'maint' and 'master' > branches in the current branching scheme. >=20 > * The (new) 'next' branch will be reserved for the development > of the next major release; it will basically take over the rule > that is currently fulfilled by the 'master' branch. >=20 > * 'maint' will be kept regularly merged into 'master', and > 'master' into 'next' (and 'next' into the 'ng/master', which > is where the Automake-NG codebase currently live). >=20 > * Feature branches should typically be based off of 'master', > and we can decide later whether to eventually merge them into > 'master' or into 'next'. >=20 > * None of 'maint', 'master' and 'next' should be rewindable. >=20 > If you agree with my proposal, I think the new schemes could be > implemented right after the 1.13.2 release; so that the planned > Automake 1.13.3 will be released as 1.14, and the planned Automake > 1.14 will be released as Automake 2.0. I think it would be better to start with the planned 1.14 (aka 2.0) rather than with 1.13.3. It makes it a cleaner break for people (aka Debian to some degree) who were relying on the old versioning scheme. =20 > And of course, we'll have to publicize the new versioning scheme > ASAP, and with quite high visibility. I propose the following > avenues: >=20 > - A news item in the savannah AUtomake page; > - A message to autotools-announce; > - An entry in the NEWS file of 1.13.2. > - ??? (suggestions welcome) >=20 > -*-*- >=20 > Feedback, opinions, objections? >=20 > Regards, > Stefano >=20 --=20 Eric Dorland ICQ: #61138586, Jabber: hooty@jabber.com --qfesBOB4TKwppX3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlEJi30ACgkQYemOzxbZcMZdWgCgtrgv1cneckp6aQYd3S6BQbkC BC4An3/OB8g4+TSzfqmxszzPvFnRzn7f =QgYK -----END PGP SIGNATURE----- --qfesBOB4TKwppX3D-- From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 31 Jan 2013 12:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org X-Debbugs-Original-To: automake@gnu.org, bug-automake@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.135963469216267 (code B ref -1); Thu, 31 Jan 2013 12:19:02 +0000 Received: (at submit) by debbugs.gnu.org; 31 Jan 2013 12:18:12 +0000 Received: from localhost ([127.0.0.1]:57012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0t5m-0004EJ-Ur for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:18:11 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48081) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0t5k-0004EB-A6 for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:18:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0t51-0003Lk-9v for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:17:26 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:60372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0t51-0003Lc-5x for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:17:23 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0t4z-00025F-Pb for bug-automake@gnu.org; Thu, 31 Jan 2013 07:17:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0t4y-0003Ka-49 for bug-automake@gnu.org; Thu, 31 Jan 2013 07:17:21 -0500 Received: from mail-ea0-f170.google.com ([209.85.215.170]:35007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0t4u-0003Jm-Q0; Thu, 31 Jan 2013 07:17:16 -0500 Received: by mail-ea0-f170.google.com with SMTP id a11so1165880eaa.1 for ; Thu, 31 Jan 2013 04:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sOtnzRCtPLNGGa7kDgv9HL/xOo4FVzcE3XwS0lasOh4=; b=f5yHox5/95iW5Eycxl4/Mf8q60V2e4xl6x4Jwp+3GPgQPlf9fvHAnp048VYFeUhBIq ptirnQszhVfGI95CM7s7i/e5bK102BlKkW/bv3/VNyTwHcTkU7RTEJ6RZwcQyrRjIbQ/ gyfgmcMpBxG5o0jB1DMy4W+UqZeXkfkQE8y/G4LcbKsMGxcai4x4swixRIk7rocNZYx6 b/eHhqMtXC+GwGwxf4alBJeBTILyzjeDbok7uUppA+gj6sGhbdLWm+QyfJ4wbWSYSIVs LcVY0KxOZDclIKpUmzAUpZuY7oH9OcNpO94S/jLqwI3DsXpCcgs1EXOjqNtKKr0EUONi T4Kg== X-Received: by 10.14.213.67 with SMTP id z43mr26758363eeo.18.1359634635638; Thu, 31 Jan 2013 04:17:15 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id g2sm7110071eep.16.2013.01.31.04.17.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 04:17:14 -0800 (PST) Message-ID: <510A60C8.3010904@gmail.com> Date: Thu, 31 Jan 2013 13:17:12 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <20130130210709.GX20353@gambit> In-Reply-To: <20130130210709.GX20353@gambit> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On 01/30/2013 10:07 PM, Eric Dorland wrote: > > [SNIP PROPOSAL for new versioning scheme] > > I like it. > Glad to hear that :-) > I think it would mean that Debian could carry less > simultaneous automake packages at the same time, ie it would have a > separate package per major release and just upgrade that to highest > release within that major (eg package automake-2 @ version 2.1.3, > automake-3 @ version 3.0.4). > > [SNIP PROPOSAL for new branching scheme] > >> If you agree with my proposal, I think the new schemes could be >> implemented right after the 1.13.2 release; so that the planned >> Automake 1.13.3 will be released as 1.14, and the planned Automake >> 1.14 will be released as Automake 2.0. > > I think it would be better to start with the planned 1.14 (aka 2.0) > rather than with 1.13.3. > While this move would have its merits, I think we should go ahead and implement the new scheme right after the 1.13.2 release [1]. That is because the current code in maint [2] already have some new features and new warnings implemented, and that is exactly the situation where a new minor version would be warranted according to the new proposed scheme. [1] But not before we have reached a consensus on the proposal, of course; as Diego pointed out, this is not something to be rushed. [2] That would have become 1.13.3 with the old versioning scheme, and should become 1.14 with the new one. > It makes it a cleaner break for people (aka Debian to some degree) > who were relying on the old versioning scheme. > Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 31 Jan 2013 12:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Cc: 13578@debbugs.gnu.org, automake@gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org, Automake List Received: via spool by submit@debbugs.gnu.org id=B.135963653122354 (code B ref -1); Thu, 31 Jan 2013 12:49:02 +0000 Received: (at submit) by debbugs.gnu.org; 31 Jan 2013 12:48:51 +0000 Received: from localhost ([127.0.0.1]:57031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0tZT-0005oV-7M for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:48:51 -0500 Received: from eggs.gnu.org ([208.118.235.92]:55824) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0tZQ-0005oK-4m for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:48:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0tYi-0003DD-Om for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:48:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:55513) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0tYi-0003D8-LQ for submit@debbugs.gnu.org; Thu, 31 Jan 2013 07:48:04 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0tYh-0000hB-2v for bug-automake@gnu.org; Thu, 31 Jan 2013 07:48:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0tYf-0003CX-Ii for bug-automake@gnu.org; Thu, 31 Jan 2013 07:48:03 -0500 Received: from mail-ee0-f42.google.com ([74.125.83.42]:44433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0tYY-00038s-1y; Thu, 31 Jan 2013 07:47:54 -0500 Received: by mail-ee0-f42.google.com with SMTP id b47so1504563eek.29 for ; Thu, 31 Jan 2013 04:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dM2ZxuEtqpxEJ1bMdv2M1EkBom7K1RFymoq68+uQJLo=; b=royi+wDrCedDvjSxpMTCf0ufQ0RyMs9qvzpA0+/vvXpQ4cWr49tASLZ+PnEDXpr2Om aXwZEheDSj2vNNSsgf258FoRPQ3dVC8TCiEdnekxy6fk3PpdpeHshuwKhqrmKjzT6ENQ KRCsp/1WjqUe0XJ8H6vSO1ATJgOXJX4qDJLGWMJwZlaYNRe+nGrBvLPmJUHClSlkenu0 SYBaJ6L4Zga7hu91m/RwPnaE8MGBE36EFagaQbtvT+wBnhTNCKcRHxy2uSo20xKCs57g FydbU/tm0CzhAJE/quL0E7iWwFnFsprXAHA+iyDZ1QjACRippKxhOPfqlkPdycV/p+FA MM5w== X-Received: by 10.14.221.9 with SMTP id q9mr27243652eep.3.1359636473011; Thu, 31 Jan 2013 04:47:53 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id d3sm7230696eeo.13.2013.01.31.04.47.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 04:47:52 -0800 (PST) Message-ID: <510A67F5.5020904@gmail.com> Date: Thu, 31 Jan 2013 13:47:49 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> In-Reply-To: <510A5980.7010801@flameeyes.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Hi Diego. On 01/31/2013 12:46 PM, Diego Elio Pettenò wrote: > On 28/01/2013 20:48, Stefano Lattarini wrote: >> Feedback, opinions, objections? > > First of all, I would like to hope that this is not going to be rushed > through — it's an important and big change > Agreed. > and I think having discussion about it with others might be a better > idea. > But there is already such a discussion going on; see: Or did you mean something else? > One thing that worries me at first thought is how often do you expect a > new major version to be out; once an year? twice an year? once every two > years? > I think that, with the new freedom the minor versions would give us to implement new features and do code optimization and refactoring, we could aim to have a new major version every 18 or 24 months (this too should be registered in HACKING). > That rate is going to be the one thing that makes or breaks it > from an automake consumer prospective I think. > Good point. > Another thing that I think is important, that ties into the versioning > scheme even though it's not really part of it would be to make two > things cleaner: > > - what in Gentoo we call "slotting": i.e. the ability to install > multiple automake versions in parallel; we have our own wrapper scripts > maintained by Mike Frysinger, I think they were originally imported from > Mandriva; I'm pretty sure other distributions have other similar > wrappers... if instead of everybody having our own, we had a single > maintained tool for the job, that would probably be a nice thing; while > adding a suffix to the build solves most of the collisions between > automake versions, info manuals for instance do not get renamed; > Since the scripts, the data directories and the manual pages are already versioned (with both major and minor version), adding support for versioned info pages might be enough to solve this issue. Then, we might even add a new option to Automake's configure to ensure only versioned stuff is installed (that is, no 'bin/automake' link to 'bin/automake-1.13', no 'man1/automake.1' manapge containing ".so man1/automake-1.13.1", etc), if that can make packagers' life even simpler. Patches in these direction would be welcome (I don't know when and if I'm going to write them myself, sorry). > - ability for a configure script to check for automake version; > Isn't it too late to check for that at configure runtime? You probably want some m4 macro that let you discriminate between different versions at automake/autoconf runtime, right? (Your further elaboration below seem to imply that the answer to this question is "yes"). > yes I know it's not the usually-proposed method to deal with it, but most > projects would like to have something like that at this point. Otherwise > we end up with m4_ifdef hacks that are just that: hacks. > Especially if moving in the direction of multiple major versions, there > are packages that would like to have their build system re-buildable on > RHEL5 as well the latest Debian or Gentoo, and then they'll end up with > nasty hacks, or requiring an older automake version and hope it doesn't > cause other issues. Having a way to test whether we're running automake > X.Y or later would be nice (and not just export the version value or > people will mess up the test for "2.1", I've seen that happen too often > for GCC or BerkDB). > This might be a useful enhancement. Does Autoconf offer enough pre-canned macros to compare version numbers at runtime? It seems it does [1], so it might be enough to add a new automake-provided macro, modelled on the autoconf-provided 'AC_AUTOCONF_VERSION' [2], that defines the current Automake version. AM_AUTOMAKE_VERSION sounds like the natural name... But see below. [1] http://www.gnu.org/software/autoconf/manual/autoconf.html#m4_005fversion_005fcompare [2] http://www.gnu.org/software/autoconf/manual/autoconf.html#Versioning Unfortunately, the 'AM_AUTOMAKE_VERSION' name is already taken for another macro: $ cd src/automake $ cat m4/amversion.m4 ... # AM_AUTOMAKE_VERSION(VERSION) # ---------------------------- # Automake X.Y traces this macro to ensure aclocal.m4 has been # generated from the m4 files accompanying Automake X.Y. # (This private macro should not be called outside this file.) AC_DEFUN([AM_AUTOMAKE_VERSION], [am__api_version='1.13a' dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to dnl require some minimum version. Point them to the right macro. m4_if([$1], [1.13a], [], [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl ]) However, that macro is private and only used internally (and cause a fatal error if a user mistakenly tries to use it), so we might safely rename it to something more appropriate, and free the name for the new proposed usage. Again, patches in this direction would be welcome. Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 31 Jan 2013 13:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Daniel Herring Cc: 13578@debbugs.gnu.org, automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.135963733123556 (code B ref 13578); Thu, 31 Jan 2013 13:03:02 +0000 Received: (at 13578) by debbugs.gnu.org; 31 Jan 2013 13:02:11 +0000 Received: from localhost ([127.0.0.1]:57051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0tmL-00067r-Br for submit@debbugs.gnu.org; Thu, 31 Jan 2013 08:02:11 -0500 Received: from mail-ea0-f175.google.com ([209.85.215.175]:54069) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0tmI-00067i-AP for 13578@debbugs.gnu.org; Thu, 31 Jan 2013 08:02:08 -0500 Received: by mail-ea0-f175.google.com with SMTP id d1so1205947eab.34 for <13578@debbugs.gnu.org>; Thu, 31 Jan 2013 05:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MpyJeisjSBDAHogRot44vUtxjyaeVsO+dMt1s/ikN/Y=; b=jgOcBi1f837SMvULJeG4zAaAtabKrvpUuzA5UBmVz/oagwHovlUTD3i0WqeR+uWn+q V+PWTBZWfQU8v3F2P+pzk5okzijD+6X5WTfz27771m/1QpIqfZr/i5eXkJl26K3wvKA9 Or8rkrSN4578UxXR4It34SP7Ycs6ZIjGjZPMG5lSKX1lrz+KvUWNzoSWdq4+Ne5rXARn jrhaHyE3dfre8a4ye8mKss4/UXE9WlRvogADxTzoLZwtE7/3Y2K+k4Fuo6nfKEzB1pjQ fgrWh+z8Am9OZ680OFzBU6FSjUvo51H3pSw6Ji1NBVQiHSVjwBsdXmcpCXdewMUlR7n7 jbBw== X-Received: by 10.14.178.196 with SMTP id f44mr27134796eem.14.1359637273488; Thu, 31 Jan 2013 05:01:13 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id q5sm7282187eeo.17.2013.01.31.05.01.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 05:01:12 -0800 (PST) Message-ID: <510A6B16.6050003@gmail.com> Date: Thu, 31 Jan 2013 14:01:10 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 01/30/2013 04:30 AM, Daniel Herring wrote: > On Mon, 28 Jan 2013, Stefano Lattarini wrote: > >> Feedback, opinions, objections? > > There was a lot to read, and I confess to not giving it full justice. > > Others have already extolled the virtues of backwards compatibility. > > > Regarding some "why" questions, here's the manual entry on how versioning > is used today. > > http://www.gnu.org/software/automake/manual/html_node/API-Versioning.html > And this is a good and valid policy, but one I have unfortunately broken in practice during the last year or so. This proposal should address that breakage, restoring sane versioning semantics. > > As far as I can tell, the current proposal boils down to "bump the major > version more often". > The real issue is that the major version in currently being bumped already in practice (big new features, backward-compatibility broken in some respects), without this being reflected in the "true" version number ("hey, why have you broken backward-compatibility from 1.12 to 1.13? What is wrong with you?"). And while this is mostly my fault, fixing it will benefit everyone (in addition to healing my ego, of course :-) > That can work, but I'm not quite sold on it. I like when a major bump > means "wake up and reread the docs before upgrading" and minor bumps > mean "upgrade casually". > This is a good user-level approach that the new versioning scheme would automatically encourage. > (and aggregate changes to minimize major bumps and make them more > worthwhile) > And similarly, this is a good developer-level approach that the new versioning scheme would automatically encourage. > Here are a couple "standards" for versioning. > > http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html > http://semver.org/ > This last resource seems nice, but alas, adding support for "VERSION+BUILD" development versions might prove a little more problematic than I'd like (of course, parched are very very welcome). > The general principle being A.B.C decodes to something easy like > A = new API, breaking changes requiring human intervention > B = same API, maybe with added options, mostly just recompile > C = just bugfixes, documentation tweaks, packaging, etc. > > For example, a deprecation warning bumps B, but actually removing > the deprecated functionality bumps A. > Indeed. Something that I have guiltily failed to do in the recent Automake developement process. > As for branching, if every release is tagged, and you want to > apply a bugfix to release A.B.C, why not just create a maint-A.B > branch or the like? > For older versions, that is indeed the sanest approach. But I think we should also accept the fact that the "last-released" minor version is going to need mostly-frequent fixes (most of the will probably be suggested by the work on the next minor release), so that having a branch already and explicitly devoted to the purpose of implementing such fixes is the best and simplest setup. > Delay creating branches until they are needed. I wasn't seeing the > need for the complex branching details. > I don't think my "new" branching scheme is actually complex. May I ask what makes you label it as such? > > I agree its nearing time for a "2.0" release; there has been talk > of removing several now-deprecated functions and making other > major changes (e.g. parallel testing). > Making the "parallel harness" a default has already been implemented in 1.13; something I now quite regret not having delayed to a new major version. > Would it be possible to start collecting these into a preview/beta > release and leave the "1.0" series with its current API and > behaviors? Just a thought. > Ideally, yes; but the time for a 2.0 will only come in a year or so (as we want to give the existing non-fatal deprecation enough time to brew, and there are also plans for several new minor versions in the meantime). So there is no need to hurry with previews etc. > I've done the build system for several projects I'm no longer > associated with. It would be nice if the people who inherited > them don't have to rework them for a few more years. A major > version change (again, small numbers) might motivate distributions > to keep both around for a while. > Indeed; I hadn't thought about that explicitly when writing my proposal, but you making a good point (and also offering a good "between-the-line" suggestion: don't release new major versions too often). > > Hope that helps, > Daniel Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 31 Jan 2013 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: 13578@debbugs.gnu.org, automake@gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org, Automake List Received: via spool by submit@debbugs.gnu.org id=B.135965104611844 (code B ref -1); Thu, 31 Jan 2013 16:51:02 +0000 Received: (at submit) by debbugs.gnu.org; 31 Jan 2013 16:50:46 +0000 Received: from localhost ([127.0.0.1]:57847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0xLX-00034t-L4 for submit@debbugs.gnu.org; Thu, 31 Jan 2013 11:50:45 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60015) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0tmy-00068g-5j for submit@debbugs.gnu.org; Thu, 31 Jan 2013 08:02:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0tmG-0007JA-Vl for submit@debbugs.gnu.org; Thu, 31 Jan 2013 08:02:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:45748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0tmG-0007J6-Tb for submit@debbugs.gnu.org; Thu, 31 Jan 2013 08:02:04 -0500 Received: from eggs.gnu.org ([208.118.235.92]:51150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0saw-0001ia-Us for bug-automake@gnu.org; Thu, 31 Jan 2013 06:46:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0sau-0002xK-Kr for bug-automake@gnu.org; Thu, 31 Jan 2013 06:46:18 -0500 Received: from mail-ee0-f47.google.com ([74.125.83.47]:42674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0sau-0002w3-Ex for bug-automake@gnu.org; Thu, 31 Jan 2013 06:46:16 -0500 Received: by mail-ee0-f47.google.com with SMTP id e52so1408481eek.20 for ; Thu, 31 Jan 2013 03:46:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=BbsOY9/i+SAWIEmseAMQQme1ArmFzb5Dmbu4epSTkRE=; b=W8h4J/PdIALnrbG3JuQvCCaw19DMesu9Q/tPxZfSssb7Ny2DD0bwG7fmPDPfUcdptL c0m24hdMXDHMMemwO4y+FWPhLmAybYsH6LYrEBP7ZCsyfK4nOLl8Ptl1zKEbsbLdnu9j LrUVPo/aUAe0KYONdD1+8IAUrhBhwv98quW2ak68VhE3wqtuKMgrXobhiUWn063BZMRB wFgqL6nkO+ZmFbCIk8WljjS7xtfPBRp4YSAA3v+FzjavDy9V3YH1d0+wQGnwWYqbE8YZ So+wLwKkio0hTLtqBFM1/73/rAe1f6twrQRmpHYXnygGfBPuIVpia0cXl1pWqDA+JI0n c7fQ== X-Received: by 10.14.223.135 with SMTP id v7mr26442131eep.41.1359632773918; Thu, 31 Jan 2013 03:46:13 -0800 (PST) Received: from saladin.home.flameeyes.eu (adsl-ull-76-153.49-151.net24.it. [151.49.153.76]) by mx.google.com with ESMTPS id f49sm6989232eep.12.2013.01.31.03.46.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 03:46:12 -0800 (PST) Message-ID: <510A5980.7010801@flameeyes.eu> Date: Thu, 31 Jan 2013 12:46:08 +0100 From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> In-Reply-To: <5106D62B.6070007@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQmIi/V0ABZvlvz0uj8mtl5T6DiaSjmwTDN6KgiGMpVaRPquZHuuxkyUOPUaahfy7xA4Thzr X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Mailman-Approved-At: Thu, 31 Jan 2013 11:50:41 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) On 28/01/2013 20:48, Stefano Lattarini wrote: > Feedback, opinions, objections? First of all, I would like to hope that this is not going to be rushed through — it's an important and big change and I think having discussion about it with others might be a better idea. One thing that worries me at first thought is how often do you expect a new major version to be out; once an year? twice an year? once every two years? That rate is going to be the one thing that makes or breaks it from an automake consumer prospective I think. Another thing that I think is important, that ties into the versioning scheme even though it's not really part of it would be to make two things cleaner: - what in Gentoo we call "slotting": i.e. the ability to install multiple automake versions in parallel; we have our own wrapper scripts maintained by Mike Frysinger, I think they were originally imported from Mandriva; I'm pretty sure other distributions have other similar wrappers... if instead of everybody having our own, we had a single maintained tool for the job, that would probably be a nice thing; while adding a suffix to the build solves most of the collisions between automake versions, info manuals for instance do not get renamed; - ability for a configure script to check for automake version; yes I know it's not the usually-proposed method to deal with it, but most projects would like to have something like that at this point. Otherwise we end up with m4_ifdef hacks that are just that: hacks. Especially if moving in the direction of multiple major versions, there are packages that would like to have their build system re-buildable on RHEL5 as well the latest Debian or Gentoo, and then they'll end up with nasty hacks, or requiring an older automake version and hope it doesn't cause other issues. Having a way to test whether we're running automake X.Y or later would be nice (and not just export the version value or people will mess up the test for "2.1", I've seen that happen too often for GCC or BerkDB). -- Diego Elio Pettenò — Flameeyes flameeyes@flameeyes.eu — http://blog.flameeyes.eu/ From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 31 Jan 2013 16:51:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: 13578@debbugs.gnu.org, automake@gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org, Automake List Received: via spool by submit@debbugs.gnu.org id=B.135965104611849 (code B ref -1); Thu, 31 Jan 2013 16:51:03 +0000 Received: (at submit) by debbugs.gnu.org; 31 Jan 2013 16:50:46 +0000 Received: from localhost ([127.0.0.1]:57849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0xLa-000350-5h for submit@debbugs.gnu.org; Thu, 31 Jan 2013 11:50:46 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35807) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U0vc0-0000Ve-5g for submit@debbugs.gnu.org; Thu, 31 Jan 2013 09:59:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0vbH-0006hF-IH for submit@debbugs.gnu.org; Thu, 31 Jan 2013 09:58:53 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:50330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0vbH-0006h5-FS for submit@debbugs.gnu.org; Thu, 31 Jan 2013 09:58:51 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0vbC-0007Z0-4P for bug-automake@gnu.org; Thu, 31 Jan 2013 09:58:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0vbA-0006ep-3o for bug-automake@gnu.org; Thu, 31 Jan 2013 09:58:46 -0500 Received: from mail-ea0-f173.google.com ([209.85.215.173]:47028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0vb9-0006eQ-SD for bug-automake@gnu.org; Thu, 31 Jan 2013 09:58:44 -0500 Received: by mail-ea0-f173.google.com with SMTP id i1so1320824eaa.32 for ; Thu, 31 Jan 2013 06:58:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=n+jAisq+4vNpu32hrC8aGPvOcgt7ydU+BluAT9UU9cg=; b=BxF3NIQDLVSxqjODm4FAxbEx/J/qQt+2qpK0o1qZyTXtWNclYsJSrYu9az6T4eDRsH 3B6XBOMOaTfIuUs0O4PPAAN4mu8qGoiCJcP6QmJxRI5953d6HLoU9ZhOUIzOcUffMgH8 uBu43e3Prpo5VIvSZRpw1zNRIDya9IZKbhg1nc3ldwDQUdNGDtw6NIIv0owfkrJL/kCc INDeMZlb4UzJSoCIGt1HcXIv23tEDGU4JK4ehyhmjwpRWOdmEiyDVwxqnfJA7J437YAr rSJMdhKfbivvyd5r+4vF5AXp3YuW6ZOush1bglapuuvDcMHQDy2yBMf5U+PGeh9bLYPH 9qUQ== X-Received: by 10.14.209.131 with SMTP id s3mr27802200eeo.26.1359644322730; Thu, 31 Jan 2013 06:58:42 -0800 (PST) Received: from saladin.home.flameeyes.eu (adsl-ull-76-153.49-151.net24.it. [151.49.153.76]) by mx.google.com with ESMTPS id 46sm7775753eeg.4.2013.01.31.06.58.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 06:58:41 -0800 (PST) Message-ID: <510A869C.4010104@flameeyes.eu> Date: Thu, 31 Jan 2013 15:58:36 +0100 From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> In-Reply-To: <510A67F5.5020904@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnwXkU6lMnviSB35pHWmb0sCP0wPEgOMeq58gN6qQ3rzRi5mNBuBvjLvjLca2s45dpY5V6b X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Mailman-Approved-At: Thu, 31 Jan 2013 11:50:41 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) On 31/01/2013 13:47, Stefano Lattarini wrote: > But there is already such a discussion going on; see: > > > > Or did you mean something else? I would expect a more ... visible discussion. Honestly bugs are all nice and shiny but I don't expect most of the automake consumers out there to even know where to find them (debbugs is handy with the email interface, but it's not exactly the nicest way to find and follow bugs, IMHO). I'll probably write a blog post myself about it to get some attention to it. > I think that, with the new freedom the minor versions would give us to > implement new features and do code optimization and refactoring, we could > aim to have a new major version every 18 or 24 months (this too should be > registered in HACKING). Okay that sounds reasonable. I would be more toward 24 than 18 — maybe going for 18 to the next "beta"-quality automake, 24 to the final release. Speaking of which I would suggest that we call X.0 the betas, and suggest general usage only when X.1 is out... > Since the scripts, the data directories and the manual pages are already > versioned (with both major and minor version), adding support for versioned > info pages might be enough to solve this issue. To a point. While it allows the multiple installation it does not help to solve the difference in multiple-automake changing between distributions. My hope would be for something like that to get rid of most of the "try-to-find-automake-version-X" logic in autogen.sh scripts (the moment when autogen.sh scripts can finally DIAF, I'll rejoice). > Then, we might even add a > new option to Automake's configure to ensure only versioned stuff is > installed (that is, no 'bin/automake' link to 'bin/automake-1.13', no > 'man1/automake.1' manapge containing ".so man1/automake-1.13.1", etc), > if that can make packagers' life even simpler. Sounds like a good idea... > Isn't it too late to check for that at configure runtime? You probably > want some m4 macro that let you discriminate between different versions > at automake/autoconf runtime, right? (Your further elaboration below > seem to imply that the answer to this question is "yes"). Sorry I wasn't clear enough, I don't expect it to be found at ./configure time, but rather at autoconf time. So that one can decide whether they want to use silent-rules, dist-xz, serial-tests and so on.. Don't assume that it's easy to install a newer automake on older systems to work during development, because as I noted above, every distribution has its way to wrap automake, and none that I know allows you a decent way to integrate an user-provided version. -- Diego Elio Pettenò — Flameeyes flameeyes@flameeyes.eu — http://blog.flameeyes.eu/ From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Jack Kelly Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 31 Jan 2013 20:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Cc: 13578@debbugs.gnu.org, Stefano Lattarini , automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.135966235228932 (code B ref 13578); Thu, 31 Jan 2013 20:00:02 +0000 Received: (at 13578) by debbugs.gnu.org; 31 Jan 2013 19:59:12 +0000 Received: from localhost ([127.0.0.1]:58092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U10Hv-0007Wb-Ph for submit@debbugs.gnu.org; Thu, 31 Jan 2013 14:59:12 -0500 Received: from mail-pb0-f52.google.com ([209.85.160.52]:44442) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U10Ht-0007WU-Rt for 13578@debbugs.gnu.org; Thu, 31 Jan 2013 14:59:11 -0500 Received: by mail-pb0-f52.google.com with SMTP id mc8so1013940pbc.11 for <13578@debbugs.gnu.org>; Thu, 31 Jan 2013 11:58:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=vucXcakBjVd/GR1j8UqxoBPzzEk4MeFqlIFZDqfW0MA=; b=VpQAaAKtpixha2VtSq7e0M9mMC6k+SOPwlTv18vBoKNIVEevlR7ZTGEszH/28L8Pf4 ttGP76ejbOFs2S+eDQRYsZqTTa8Z+KssHqLy3txYItQgA8U0SVL4tGZumEVl4vyDCZnP H1uh4G2QrxMiHySIrSyNlVyFbJ02opkKp/phj/INawWOuRgjadoLnRStLl36GWWGjbhD RmDdK0lXOQmAuArY07FNOLVScXtnW/m17kGu27XI9v1F5NAFD//m1Lm4QJddvXlWZyrw QLlYfpr6vtIDFuISl2R5K49biDGbUA6AOa5gETdC8bEBP12BBPbrNysMrPeM9v9Lm9mQ np9g== X-Received: by 10.66.79.74 with SMTP id h10mr23547307pax.25.1359662305452; Thu, 31 Jan 2013 11:58:25 -0800 (PST) Received: from handybilly ([125.253.98.148]) by mx.google.com with ESMTPS id b3sm3850438pax.14.2013.01.31.11.58.22 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 31 Jan 2013 11:58:24 -0800 (PST) From: Jack Kelly References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> Date: Fri, 01 Feb 2013 06:58:14 +1100 In-Reply-To: <510A869C.4010104@flameeyes.eu> ("Diego Elio =?UTF-8?Q?Petten=C3=B2?="'s message of "Thu, 31 Jan 2013 15:58:36 +0100") Message-ID: <87622dxgyx.fsf@jackkelly.name> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlbUJYvujtlnChmFxNc/JgP1v0tPJjOBH/AbbldoflfnhS/lRVCV4W2I3g8/flJvIAX+SdW X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Diego Elio Petten=C3=B2 writes: > Okay that sounds reasonable. I would be more toward 24 than 18 =E2=80=94 = maybe > going for 18 to the next "beta"-quality automake, 24 to the final > release. Speaking of which I would suggest that we call X.0 the betas, > and suggest general usage only when X.1 is out... IMHO, that seems like a great way to cause trouble for unsuspecting users. (Anyone remember KDE4.0?) Can you expand on why you think it's a good plan? Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit the ordering system for most package managers? Bonus points if it works in asciibetical order, too. -- Jack From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Fri, 01 Feb 2013 00:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Jack Kelly Cc: 13578@debbugs.gnu.org, Stefano Lattarini , automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.135967744122041 (code B ref 13578); Fri, 01 Feb 2013 00:11:01 +0000 Received: (at 13578) by debbugs.gnu.org; 1 Feb 2013 00:10:41 +0000 Received: from localhost ([127.0.0.1]:58255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U14DH-0005jQ-Gb for submit@debbugs.gnu.org; Thu, 31 Jan 2013 19:10:41 -0500 Received: from mail-ee0-f47.google.com ([74.125.83.47]:56543) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U14DE-0005jG-Rk for 13578@debbugs.gnu.org; Thu, 31 Jan 2013 19:10:38 -0500 Received: by mail-ee0-f47.google.com with SMTP id e52so1780748eek.34 for <13578@debbugs.gnu.org>; Thu, 31 Jan 2013 16:09:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=e//nN+AMibQ4YOCwDT9F0qI5QUGWCSLPURCsAnfVFdk=; b=WxMfn3/bujKpyMvUwSeptFIM2bP/teidbXWUujUev7poi92n0wkOwtJ/lpOkYkn3yv l0pSGgURfWFHgDch2gC0ZeMK3clCRs2IGbtxiH1FBQgQpJo35E9wid8qSqDDzghdkT+M d6Frgk7nDgeOKE2ww8ndgoNorvTwStoRE3gUGjw7gpB4dtPqYsLd0QhI2vMAZ+JgLSkW EyabgQKwz9lbqJ/WvTN67/490y+e5iq0ZcQWFDrOz0ecvnu9U5lLhlIDLJCUKAq56N1r Wy5mJyBw6CXKN1ka1KM7/3+SRYtNegHtR2ut2xGAPmC1bjSyPDbv8zhre2vai+tBrfaG e9/w== X-Received: by 10.14.173.196 with SMTP id v44mr32778407eel.29.1359677391123; Thu, 31 Jan 2013 16:09:51 -0800 (PST) Received: from saladin.home.flameeyes.eu (adsl-ull-76-153.49-151.net24.it. [151.49.153.76]) by mx.google.com with ESMTPS id f6sm9945621eeo.7.2013.01.31.16.09.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 16:09:49 -0800 (PST) Message-ID: <510B07C8.2070108@flameeyes.eu> Date: Fri, 01 Feb 2013 01:09:44 +0100 From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> In-Reply-To: <87622dxgyx.fsf@jackkelly.name> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkEdJuYu5HM6ZpH5ukSIb1Y3TOeRB7AnR06uh9avcKyS12Kd6fQ6K5xKHotFiisZwlstNfe X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 31/01/2013 20:58, Jack Kelly wrote: > IMHO, that seems like a great way to cause trouble for unsuspecting > users. (Anyone remember KDE4.0?) Can you expand on why you think it's a > good plan? Because unlike KDE, automake can put a big fat warning in the generated configure that says "You're using a version unsuitable for production", and then people would understand it much better. KDE 4.0 was a screwup because there was no big fat warning, and users insisted to have it. No user _asks_ for automake. > Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit > the ordering system for most package managers? Bonus points if it works > in asciibetical order, too. Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y for almost everything but autotools.. -- Diego Elio Pettenò — Flameeyes flameeyes@flameeyes.eu — http://blog.flameeyes.eu/ From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Jack Kelly Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Fri, 01 Feb 2013 05:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Cc: 13578@debbugs.gnu.org, Stefano Lattarini , automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.135969785326170 (code B ref 13578); Fri, 01 Feb 2013 05:51:01 +0000 Received: (at 13578) by debbugs.gnu.org; 1 Feb 2013 05:50:53 +0000 Received: from localhost ([127.0.0.1]:58451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U19WX-0006o3-C6 for submit@debbugs.gnu.org; Fri, 01 Feb 2013 00:50:53 -0500 Received: from mail-da0-f46.google.com ([209.85.210.46]:65227) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U19WT-0006nu-88 for 13578@debbugs.gnu.org; Fri, 01 Feb 2013 00:50:51 -0500 Received: by mail-da0-f46.google.com with SMTP id p5so1603016dak.33 for <13578@debbugs.gnu.org>; Thu, 31 Jan 2013 21:50:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=VCfzQHCJNd5baf19kbJutNtQNMKUDkK8bX37sCsDlGI=; b=NlmpS8mvqC45ddzR9NE8EL/LUEp28s477Quaaue1eSal9hP+IinBrta/PdALmhIuw8 XpNmjQHGcHDN7xgp4rRHfGLZR2PEWqEozyugxk8hdfYFpdXRLh5z76ce035zcrAy+IEu UPbHA28fSFkelBpj90CL0xUEz3RBSFDHXPulJTVccat/I/7cOComJjchgaG7ZrNIx9hR eGqFX6hcbnKKKG12QFGJ8j03Z4axSjmMnJPCbD+V8lB73nGHtPTSZB0Y1pwgqOVS98uV JodXJg2Tko+raDNh9RZVSCTVWZAVj4XMzCRPMgQ9R7cRBR0NPq+4KnzhcEcz+vudWUXt 9wZQ== X-Received: by 10.68.241.232 with SMTP id wl8mr28743562pbc.144.1359697802334; Thu, 31 Jan 2013 21:50:02 -0800 (PST) Received: from handybilly ([125.253.98.148]) by mx.google.com with ESMTPS id ti9sm7340191pbc.16.2013.01.31.21.49.58 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 31 Jan 2013 21:50:01 -0800 (PST) From: Jack Kelly In-Reply-To: <510B07C8.2070108@flameeyes.eu> ("Diego Elio \=\?utf-8\?Q\?Petten\?\= \=\?utf-8\?Q\?\=C3\=B2\=22's\?\= message of "Fri, 01 Feb 2013 01:09:44 +0100") Date: Fri, 01 Feb 2013 16:47:40 +1100 Message-ID: <87wquswpoj.fsf@jackkelly.name> References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmOi0kaJgYIoxEjmEySleQskKj8cEAnko8Pk6xNKLCX0GpgA9LUYkZvWUjeszk+1fgc6NRb X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Diego Elio Petten=C3=B2 writes: > On 31/01/2013 20:58, Jack Kelly wrote: >> IMHO, that seems like a great way to cause trouble for unsuspecting >> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a >> good plan? > > Because unlike KDE, automake can put a big fat warning in the generated > configure that says "You're using a version unsuitable for production", > and then people would understand it much better. Or at automake invocation time? > KDE 4.0 was a screwup because there was no big fat warning, and users > insisted to have it. No user _asks_ for automake. > >> Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit >> the ordering system for most package managers? Bonus points if it works >> in asciibetical order, too. > > Good luck finding one. Gentoo would be fine with X.Y_betaZ =E2=80=94 but I > honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y > for almost everything but autotools.. Fair points. +1 to calling the betas "X.0". -- Jack From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 03 15:39:10 2013 Received: (at control) by debbugs.gnu.org; 3 Feb 2013 20:39:10 +0000 Received: from localhost ([127.0.0.1]:34602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U26LG-0002Ic-G0 for submit@debbugs.gnu.org; Sun, 03 Feb 2013 15:39:10 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:39498) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U26LE-0002IV-7N for control@debbugs.gnu.org; Sun, 03 Feb 2013 15:39:09 -0500 Received: by mail-ea0-f172.google.com with SMTP id f13so2595893eaa.3 for ; Sun, 03 Feb 2013 12:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; bh=Lo/QMTI9GiKVHiggbgTXaiZ6PrZFpW95V+3+tnqT8wg=; b=zCBAH+Dq0D4qcpAoTPW2dGTEe9czJsezdbM0lenmtjiHmy3TzBsrLLXE6R8xohasX+ S/ptQSpA1SNowWzvr2K50qY0RBXs4/HGqZYbuwnyI9J9yt4HillVsoQUCkS7fKhkdiMv 6Fmt99twX1njxaCC+wXhu3e6b21qOkThHvb8sAGj2K8MvGjJLZs/F42cuf855J1LAzPE ii1yIqaT6C5s7GWmyI440oIAblwLx0I3uwhH2ry2CwzlLzWVbHvfPA+VsAnXpiYhxlyT QaGmAA54zkICEOAsFlAa5wmc9s/W2TzwY5BAx0BxhHlBGFrQHLF271okw3rBRuL0KJ4m FVrw== X-Received: by 10.14.2.5 with SMTP id 5mr64688567eee.30.1359923886802; Sun, 03 Feb 2013 12:38:06 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id h5sm23890426eem.1.2013.02.03.12.38.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 12:38:06 -0800 (PST) Message-ID: <510ECAAB.6060502@gmail.com> Date: Sun, 03 Feb 2013 21:38:03 +0100 From: Stefano Lattarini MIME-Version: 1.0 To: control@debbugs.gnu.org Subject: 13578 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) retitle 13578 A new versioning scheme for automake releases, and a new branching scheme for the Git repository stop From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 11 Feb 2013 14:56:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Jack Kelly Cc: 13578@debbugs.gnu.org, Diego Elio =?UTF-8?Q?Petten=C3=B2?= , automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13605945499639 (code B ref 13578); Mon, 11 Feb 2013 14:56:06 +0000 Received: (at 13578) by debbugs.gnu.org; 11 Feb 2013 14:55:49 +0000 Received: from localhost ([127.0.0.1]:50839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4unI-0002Ux-Dp for submit@debbugs.gnu.org; Mon, 11 Feb 2013 09:55:48 -0500 Received: from mail-we0-f179.google.com ([74.125.82.179]:54175) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4unB-0002Tj-Ud for 13578@debbugs.gnu.org; Mon, 11 Feb 2013 09:55:42 -0500 Received: by mail-we0-f179.google.com with SMTP id x43so4772489wey.38 for <13578@debbugs.gnu.org>; Mon, 11 Feb 2013 06:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5GVb5bevNvQBCe4JJAEDl3ogHbbwUN3HrvzxUdOnwzM=; b=X8xHtBkmswXBFa1KAgBISdS5hydhAqZDm5SMZCKF3fECoaeEHiQXNGz2aKv/lruRhI 7EZb4rEeifzRWTahDi7IkIqtxJzpNcM04HoIQsPDKJZICHXsh+WVTx7kxPnSGNydJNMq JU2t8Ix4BG2VpDHoyARc/yfkupsUFskVZVnF+zun9Qnn4sjYhSYhFpF2i6WKOkoMWbfZ td6DNx0y04QiqiiCsrhFTAcV0eKgHi33HiDcp0r2S/SwuDcfg9AD6/55m16TAhyxnZDh xNTev7mNwXTSIDIJGbsB2ukLYCZZXV5RtAPKKCTBBQlfdym5IpJHNJlfsbNWCIHC5jEI JFKA== X-Received: by 10.194.21.163 with SMTP id w3mr1721022wje.56.1360594501675; Mon, 11 Feb 2013 06:55:01 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id q13sm32087230wie.0.2013.02.11.06.54.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 06:55:00 -0800 (PST) Message-ID: <51190641.2080803@gmail.com> Date: Mon, 11 Feb 2013 15:54:57 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> In-Reply-To: <87wquswpoj.fsf@jackkelly.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) Hi Diego, Jack, sorry for the late reply. On 02/01/2013 06:47 AM, Jack Kelly wrote: > Diego Elio Pettenò writes: >> On 31/01/2013 20:58, Jack Kelly wrote: >>> IMHO, that seems like a great way to cause trouble for unsuspecting >>> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a >>> good plan? >> >> Because unlike KDE, automake can put a big fat warning in the generated >> configure that says "You're using a version unsuitable for production", >> and then people would understand it much better. > > Or at automake invocation time? > >> KDE 4.0 was a screwup because there was no big fat warning, and users >> insisted to have it. No user _asks_ for automake. >> >>> Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit >>> the ordering system for most package managers? Bonus points if it works >>> in asciibetical order, too. >> >> Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I >> honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y >> for almost everything but autotools.. > > Fair points. +1 to calling the betas "X.0". > But what if we want to have multiple betas for, say, Automake 1.14? Today, we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme you are proposing? As for the naming scheme for alpha/beta versions in Automake: I agree it is suboptimal and a little confusing, its roots being likely based in the messy 1.4 -> 1.6 transition. So far, it hasn't yet grated on me enough to motivate me to try to improve it [1]; but if anyone wants to take a shot at that, be my guest! (that will probably require some mail archive digging and "git blame" invocations to see who introduced what for which reason). [1] In a way that is enough backward compatible, I mean. Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 11 Feb 2013 15:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini , Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136059486310182 (code B ref 13578); Mon, 11 Feb 2013 15:02:02 +0000 Received: (at 13578) by debbugs.gnu.org; 11 Feb 2013 15:01:03 +0000 Received: from localhost ([127.0.0.1]:51017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4usQ-0002eA-Pl for submit@debbugs.gnu.org; Mon, 11 Feb 2013 10:01:03 -0500 Received: from mail-ea0-f175.google.com ([209.85.215.175]:59941) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4usM-0002dk-7R for 13578@debbugs.gnu.org; Mon, 11 Feb 2013 10:01:01 -0500 Received: by mail-ea0-f175.google.com with SMTP id d1so2698174eab.20 for <13578@debbugs.gnu.org>; Mon, 11 Feb 2013 07:00:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=NO0HkOOhxMoltC3AelQWMlG/1Rvu9cXH510GxAqOvsg=; b=T+HyDtyRk/qDCevY+oI0ZB3Wi5Fvpgdcg8lUBin/Lztt+xkhDbXxMTvUV+xxfZN6Fq fMV8955G6L7bjHpmEN7X7nRtBJd7rfUWwrPLsgonnz+P4UW9ToHeaStgnHYxvDbzlkHc s12ot2faMWdfSTbADwal0kzfHLx0VoAZbOVhkatv2DBPbyylmCHnutZ3RlXF2C8bRnDZ P7yYY87jYOb8fPWcZQi2wgl7egklAS/FwRTm1ulUQlwyOcyWAh1NzDosSCTLgqrY20p+ E6S7fTeMnUS1ME+l8nIjuRI/nq8bgD77hogt3mhoIyX7KxWAJ/H6nDQWDAnq8AGD6pYA GWwA== X-Received: by 10.14.179.5 with SMTP id g5mr50916600eem.41.1360594837073; Mon, 11 Feb 2013 07:00:37 -0800 (PST) Received: from saladin.home.flameeyes.eu (adsl-ull-109-154.49-151.net24.it. [151.49.154.109]) by mx.google.com with ESMTPS id d47sm4164856eem.9.2013.02.11.07.00.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 07:00:35 -0800 (PST) Message-ID: <51190792.9070902@flameeyes.eu> Date: Mon, 11 Feb 2013 16:00:34 +0100 From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> In-Reply-To: <51190641.2080803@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQmYYQUJOj6ei/kFXx6xpryvYtxCgLFH3fo86nhC7pb3rNlk8ESp6kvG/biz2AbfSXGzR1Ga X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) On 11/02/2013 15:54, Stefano Lattarini wrote: > But what if we want to have multiple betas for, say, Automake 1.14? Today, > we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme > you are proposing? Given that 1.12.0 was "not really final release", and 1.13.0 _and_ .1 were "not really final releases", I would suggest calling the first beta as 1.14.0 with the big fat warning, then everybody's satisfied (no missing features, for instance), it rolls as 1.14.4 (say) "really final release". This should be more or less equivalent to Apache's versioning, and leads to decency, I'd say. -- Diego Elio Pettenò — Flameeyes flameeyes@flameeyes.eu — http://blog.flameeyes.eu/ From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 11 Feb 2013 23:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: automake@gnu.org, Jack Kelly , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136062669031061 (code B ref 13578); Mon, 11 Feb 2013 23:52:02 +0000 Received: (at 13578) by debbugs.gnu.org; 11 Feb 2013 23:51:30 +0000 Received: from localhost ([127.0.0.1]:51217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U539m-00084w-30 for submit@debbugs.gnu.org; Mon, 11 Feb 2013 18:51:30 -0500 Received: from smtp11.dentaku.gol.com ([203.216.5.73]:36941) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U539i-00084m-KN for 13578@debbugs.gnu.org; Mon, 11 Feb 2013 18:51:27 -0500 Received: from 218.231.148.126.eo.eaccess.ne.jp ([218.231.148.126] helo=catnip.gol.com) by smtp11.dentaku.gol.com with esmtpa (Dentaku) (envelope-from ) id 1U539J-0006k4-6l; Tue, 12 Feb 2013 08:51:01 +0900 Received: by catnip.gol.com (Postfix, from userid 1000) id 1F759DFC1; Tue, 12 Feb 2013 08:51:00 +0900 (JST) From: Miles Bader References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> System-Type: x86_64-unknown-linux-gnu Date: Tue, 12 Feb 2013 08:50:59 +0900 In-Reply-To: <51190641.2080803@gmail.com> (Stefano Lattarini's message of "Mon, 11 Feb 2013 15:54:57 +0100") Message-ID: <87ehgmpfz0.fsf@catnip.gol.com> Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) Stefano Lattarini writes: > But what if we want to have multiple betas for, say, Automake 1.14? Today, > we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme > you are proposing? There's always 1.14.0.1, ... Or the widely used in FOSS 1.13.99... [sometimes they start at "90", to leave room for updates, but I suppose you could always just use .99.1, .99.2, ...] -miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 08:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Miles Bader Cc: automake@gnu.org, Jack Kelly , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136065642412816 (code B ref 13578); Tue, 12 Feb 2013 08:08:02 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 08:07:04 +0000 Received: from localhost ([127.0.0.1]:51498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5AtL-0003Kf-Q1 for submit@debbugs.gnu.org; Tue, 12 Feb 2013 03:07:04 -0500 Received: from mail-we0-f180.google.com ([74.125.82.180]:65225) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5AtJ-0003KG-PL for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 03:07:03 -0500 Received: by mail-we0-f180.google.com with SMTP id k14so5380691wer.39 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 00:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rtYp+fQgHVU8oDd8+Dqh4J5deNmiKU1+DEn6ToYMHR8=; b=TSr8oIv3jd3ftCtXt+Vmf86X0SbK2//6yRVSwqMQAmCM39acha5JjpcKlWcgiZR5rQ HUxKID7J//bsYo4dKUhxmE93CVDZxMZJoou490mZqmUogsp1S9Z8DMBIgISAmcpSeOCJ ennWbSQMqBK5Ktb8TnJ3/4QQJL3BQ/itnjPHWsPtG59riF8ITlguy8zjSFPxZE8zYzS4 GdePlB+yWlXXTuuDpG0QH421T7YIAobqIZXKKXpQXYaPm/k4ghfpHtBo6O+CG0L/M2wd /FIJi6xhaY5YfYLRiwN/fwWphbE/5I1VNMup46Oj4pwN23LTQnIDmzXHVR06XA78QkG7 Q5KQ== X-Received: by 10.180.85.103 with SMTP id g7mr1240163wiz.29.1360656396197; Tue, 12 Feb 2013 00:06:36 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id n2sm34993704wiy.6.2013.02.12.00.06.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 00:06:35 -0800 (PST) Message-ID: <5119F7F1.3010001@gmail.com> Date: Tue, 12 Feb 2013 09:06:09 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <87ehgmpfz0.fsf@catnip.gol.com> In-Reply-To: <87ehgmpfz0.fsf@catnip.gol.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) Hi Miles. On 02/12/2013 12:50 AM, Miles Bader wrote: > Stefano Lattarini writes: >> But what if we want to have multiple betas for, say, Automake 1.14? Today, >> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme >> you are proposing? > > There's always 1.14.0.1, ... > Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers -- otherwise, we could just have 1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and 1.14 as new major release. But if that leading "1" is going to remain unchanged anyway, what is the point of keeping it? It's just "visual noise" IMO. (In addition, the current version-checking code in Automake only grasps version numbers with at most three numbers). > Or the widely used in FOSS 1.13.99... > [sometimes they start at "90", to leave room for updates, > This might work. But see below. > but I suppose you could always just use .99.1, .99.2, ...] > (No, because, as said above, I don't want to have version numbers with four or more components) Anyway, before changing the current naming scheme for beta versions, we'd need some numbers about which the most widespread naming schemes are, and weight their advantages and disadvantages w.r.t. our "workflow"; we don't want to trade the current naming scheme for another that is only marginally more popular, or for a one that will give use a new and bigger set of problems down the road. Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 08:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Cc: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136065759214542 (code B ref 13578); Tue, 12 Feb 2013 08:27:01 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 08:26:32 +0000 Received: from localhost ([127.0.0.1]:51512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BCB-0003mT-DN for submit@debbugs.gnu.org; Tue, 12 Feb 2013 03:26:32 -0500 Received: from mail-we0-f172.google.com ([74.125.82.172]:58056) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BC8-0003mM-VU for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 03:26:30 -0500 Received: by mail-we0-f172.google.com with SMTP id x10so5472770wey.31 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 00:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BJyfLLUhcKm0szVaDXQfd7LthjpTd3eREmq8CaAaX9U=; b=uj5zA5sl2YfykSIyCA3hY8e4JpUUYsQ31N+no+adzLbvqgeipVKL6jYY6qHszWiY9H 3BJJQXqT5Hb1nUSOd23Ja3igRf3a0LZ3D+560LFPPz2aS/QDcgq3MeaIs7+W27q9g+qw ANxDYPEMvBCBc0OQKm6yh/7cQ2MCk9SgrN0G20eBgahy2RW3toNTR8ZaATU/bhKMWvIe opDdHFjNU3BEacoefC8EhE0XjkbP1ywiRvW/nz9tjRZwP+hTI07GCGutt1dcbP8p4UTq ExKG+6eJsG9qsqrrpLqozSo581jn0Lw2JKvtl3wSO9bSDvDSNRVDRTRiRerFZLRvUwvc V2zA== X-Received: by 10.180.89.101 with SMTP id bn5mr1328258wib.14.1360657563676; Tue, 12 Feb 2013 00:26:03 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id l3sm38092511wiy.8.2013.02.12.00.26.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 00:26:02 -0800 (PST) Message-ID: <5119FC99.30706@gmail.com> Date: Tue, 12 Feb 2013 09:26:01 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <51190792.9070902@flameeyes.eu> In-Reply-To: <51190792.9070902@flameeyes.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/11/2013 04:00 PM, Diego Elio Pettenò wrote: > On 11/02/2013 15:54, Stefano Lattarini wrote: >> But what if we want to have multiple betas for, say, Automake 1.14? Today, >> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme >> you are proposing? > > Given that 1.12.0 was "not really final release", > Why not? > and 1.13.0 _and_ .1 were "not really final releases", > This is true, but is only due to the fact that I released them with too much haste, without giving time for proper testing. IOW, this debacle has been a fault of mine, not of the naming scheme. > I would suggest calling the first beta as 1.14.0 with the big fat > warning, > I don't see any need for this; everyone knows that a new major release is more likely to contain bugs and rough edges. (OTOH, this is not excuse to be sloppy and hastily in the release process as I've been for 1.13; but avoiding repeating the mistake in the future will only require more care and attention from the maintainer, and not a change of policy). > then everybody's satisfied (no missing features, for instance), > it rolls as 1.14.4 (say) "really final release". > > This should be more or less equivalent to Apache's versioning, > Any link about this? The info I found on Google doesn't seem very helpful nor relevant. > and leads to decency, I'd say. > Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 08:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , Jack Kelly , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136065761214572 (code B ref 13578); Tue, 12 Feb 2013 08:27:02 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 08:26:52 +0000 Received: from localhost ([127.0.0.1]:51515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BCW-0003mz-DH for submit@debbugs.gnu.org; Tue, 12 Feb 2013 03:26:52 -0500 Received: from mail-qa0-f42.google.com ([209.85.216.42]:63181) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BCU-0003mt-Ma for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 03:26:51 -0500 Received: by mail-qa0-f42.google.com with SMTP id cr7so1572538qab.1 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 00:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OYJueN4KynZv82YBgDSgL8TlxiNh8t+HNH6WSn5xVtg=; b=x3jvN5uODYjl6UkRKYn6tHqE8KFqxf2y1KfHjK4E0F769g8hlQIC2WU0S1udPTVqFU vGFAqpZkZaXyjpXZUK1B3nPBWaux5VCymZ9y5ZCkfFQVGIXl0lyhxz0tdVRivn8LpB6X FzFS+/OcS3hbt5Sn06Nkyo1RqYIYHIo0Xz27RZL9xpSNEVLbJMzYVPtWASAE2j/w+3sI qqALNX8ShIQNsqKgb8IwW7IKNTk8uoanRZ/y8z1GhrBSevE+yS4sxv2A//RW6O+4dKE+ oilVLnxsrH5YEkmXPtv7QJ2SUCrufIZWg0t6RaW+z/UdbzwUbC5X4I3Je/o8x4Gen39S Np9w== X-Received: by 10.224.146.136 with SMTP id h8mr6599018qav.97.1360657585698; Tue, 12 Feb 2013 00:26:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.83 with HTTP; Tue, 12 Feb 2013 00:25:45 -0800 (PST) In-Reply-To: <5119F7F1.3010001@gmail.com> References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <87ehgmpfz0.fsf@catnip.gol.com> <5119F7F1.3010001@gmail.com> From: Miles Bader Date: Tue, 12 Feb 2013 17:25:45 +0900 X-Google-Sender-Auth: QsZfpayH0iev_F795Iw2KvwwFtg Message-ID: Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) 2013/2/12 Stefano Lattarini : >>> But what if we want to have multiple betas for, say, Automake 1.14? Today, >>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme >>> you are proposing? >> >> There's always 1.14.0.1, ... >> > Yuck; the new versioning scheme is done exactly to avoid that kind > of overly long version numbers Well, I agree in general that too many components is yucky, but keep in mind that these _aren't releases_, so assigning them "awkward" version numbers doesn't really seem all that annoying. These really aren't part of the historical record. The existing naming scheme for betas does the same thing (uses "weird" version numbers), but is problematic because it's not mechanically consistent with "ordinary" version numbers (and so screws up cases such as packaging software). I do agree that removing the leading "1." might be a good idea if it's meaningless in practice. Linux's similar action was good. -miles -- Cat is power. Cat is peace. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 08:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Miles Bader Cc: Automake List , Jack Kelly , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136065831515642 (code B ref 13578); Tue, 12 Feb 2013 08:39:02 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 08:38:35 +0000 Received: from localhost ([127.0.0.1]:51532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BNq-00044E-K9 for submit@debbugs.gnu.org; Tue, 12 Feb 2013 03:38:35 -0500 Received: from mail-wi0-f181.google.com ([209.85.212.181]:56889) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BNo-000446-5G for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 03:38:33 -0500 Received: by mail-wi0-f181.google.com with SMTP id hm6so4059261wib.14 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 00:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=N/3XDWhT1gxWF5RzBAmk3oTsZt+DueICWbfGnzys53Q=; b=A7Rx6GBNhl/Cesj1J8hea+BDMD83qN9PqvdZNPJhV9jylTmAywVv9amLwK/pjlyY8Y vxuwc7AYCZttK9BFHaRC04Gb5Wr1eonagpL4hGSBREIoi2ydca07HCl1xJ61yaIFe/dR 58kAaFAHXFurVizwC8FlAwQT25fH/MIX8jP71f7CpZ4APfz4vmACst/qCuBFOmFHwi4t rgCdbgrtzVzZorvjyvXfgpOQfZXsMADVn6nqr5TMEqva/CK2HiYriEsEe+ImC71dNFnx FmI/eCfuaeZrexHIQd0uxbJyJpnMpGo1uJdwUz+c/+b5ZYsslo6rR5mEPlkSCiaQhGUZ xgHw== X-Received: by 10.180.7.232 with SMTP id m8mr1399747wia.8.1360658286766; Tue, 12 Feb 2013 00:38:06 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id hb9sm35146944wib.3.2013.02.12.00.38.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 00:38:05 -0800 (PST) Message-ID: <5119FF6B.80707@gmail.com> Date: Tue, 12 Feb 2013 09:38:03 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <87ehgmpfz0.fsf@catnip.gol.com> <5119F7F1.3010001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/12/2013 09:25 AM, Miles Bader wrote: > 2013/2/12 Stefano Lattarini : >>>> But what if we want to have multiple betas for, say, Automake 1.14? Today, >>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme >>>> you are proposing? >>> >>> There's always 1.14.0.1, ... >>> >> Yuck; the new versioning scheme is done exactly to avoid that kind >> of overly long version numbers > > Well, I agree in general that too many components is yucky, but keep > in mind that these _aren't releases_, so assigning them "awkward" > version numbers doesn't really seem all that annoying. These really > aren't part of the historical record. The existing naming scheme for > betas does the same thing (uses "weird" version numbers), but is > problematic because it's not mechanically consistent with "ordinary" > version numbers (and so screws up cases such as packaging software). > Mostly fair points; but the biggest issue with this proposal (not sure why I didn't think of it before, sorry) is that it is not at all clear that a version like "1.13.0.1" is supposed to be a beta release. People will easily mistake it for a stable release. OK, we can add warnings and info and whatnot in the manual and homepage of automake about our unusual versioning scheme, but how many people will read them? And in the end, even those who do will likely be just annoyed by the fact that we are trying to be clever and invent a new versioining scheme incompatible with every other existing one. No, if we want to change the versioning scheme for beta and rc versions, we want the new scheme to be already used and well known. > I do agree that removing the leading "1." might be a good idea if it's > meaningless in practice. Linux's similar action was good. > > -miles > > -- > Cat is power. Cat is peace. Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 08:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , Jack Kelly , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136065906816768 (code B ref 13578); Tue, 12 Feb 2013 08:52:02 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 08:51:08 +0000 Received: from localhost ([127.0.0.1]:51552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BZz-0004MO-Fo for submit@debbugs.gnu.org; Tue, 12 Feb 2013 03:51:08 -0500 Received: from mail-qa0-f52.google.com ([209.85.216.52]:52627) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BZy-0004MI-IP for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 03:51:07 -0500 Received: by mail-qa0-f52.google.com with SMTP id bs12so1568188qab.4 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 00:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=omwwvpMJFBKMJMqdsvF/pcT9YtSfAX1Z6Y9WCB3bPJM=; b=qBNcZFy9K+Ce6d8udPK8kKwEySeyXjAlr5n6NBui+M30r4bqGejKhvrWJQ4MM8wnyb +V27Py8O/S7ZYnffFIIeHCzKhhKhSShu6B2w+JFjxw0sTvGGmvFcTHTlUXDuD3/wsM7x cx7TQxaly0fKPAKesA+21nA4x7pBULS88pfyuI0lMm+QVFfSBkRXpCSdcV9F32eWCFnU L82oZ2ak1j9E9NbQM8eBlgJj+O2vlI4qDArQdM361SoUhc5S6aDOeH4qgNRQFJy3z6XS 81mhaZrEiGZ4zroC9M0EDE7d5etBVtgZ3peggaZe4Qjn69yxpmDROO35RvG70HquzGxk wUmQ== X-Received: by 10.224.221.145 with SMTP id ic17mr6705497qab.34.1360659041469; Tue, 12 Feb 2013 00:50:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.83 with HTTP; Tue, 12 Feb 2013 00:50:01 -0800 (PST) In-Reply-To: <5119FF6B.80707@gmail.com> References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <87ehgmpfz0.fsf@catnip.gol.com> <5119F7F1.3010001@gmail.com> <5119FF6B.80707@gmail.com> From: Miles Bader Date: Tue, 12 Feb 2013 17:50:01 +0900 X-Google-Sender-Auth: zN0GUKsipRKM64_aBK6mMfMPEK8 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) 2013/2/12 Stefano Lattarini : > Mostly fair points; but the biggest issue with this proposal (not > sure why I didn't think of it before, sorry) is that it is not at > all clear that a version like "1.13.0.1" is supposed to be a beta > release. People will easily mistake it for a stable release. How about this: pick whatever scheme you like for other reasons, and then add "-beta" to those version numbers. In other words, a purely informational suffix, which is not actually necessary for version sorting... (note that the "a", "b", etc, suffixes have the same issue) -miles -- Cat is power. Cat is peace. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 15:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136068213922065 (code B ref 13578); Tue, 12 Feb 2013 15:16:01 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 15:15:39 +0000 Received: from localhost ([127.0.0.1]:52318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Ha6-0005jp-9r for submit@debbugs.gnu.org; Tue, 12 Feb 2013 10:15:39 -0500 Received: from mail-ea0-f169.google.com ([209.85.215.169]:45643) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Ha3-0005jh-HM for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 10:15:36 -0500 Received: by mail-ea0-f169.google.com with SMTP id d13so89307eaa.28 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 07:15:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=uL9oF1s4bS59gcfjW22wBk/PnCcomH6K0PMWZDOAaGg=; b=Y1SCf+rP/M5rnPKnPPE/c1T13le9pGs8j+qM3E8Y24CkLSJQJCrAxGwATEInmxgBJv ud4Kj4ZhVTU3efCogH7GviNJyxTdJjlJ8ji0luNzFIceFMdXNFAUNxq03l2h3HAlS3cE 0zB7I5lfGzM3RudK7FHZMfjviIg7zW7iwBRgfM9ShQpm6sqi+zZGmF0qbKOWlNo/KYEZ QCZYiS0JqC2fVuqgse7OV5YGqmI9A3HdbujvMA4P4lxdAY1BxUHnBSp2jNPWa1DjP6NV nhRdiNtOsuTCnuDdRUpyjJn4CE+Z+X4e50zbuWelH68erZ7Qx4ZNQ5smCsOPvcD4elLF KDbQ== X-Received: by 10.14.194.8 with SMTP id l8mr63812344een.31.1360682108241; Tue, 12 Feb 2013 07:15:08 -0800 (PST) Received: from saladin.home.flameeyes.eu (adsl-ull-109-154.49-151.net24.it. [151.49.154.109]) by mx.google.com with ESMTPS id j46sm64951744eeo.3.2013.02.12.07.15.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 07:15:06 -0800 (PST) Message-ID: <511A5C77.9080904@flameeyes.eu> Date: Tue, 12 Feb 2013 16:15:03 +0100 From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <51190792.9070902@flameeyes.eu> <5119FC99.30706@gmail.com> In-Reply-To: <5119FC99.30706@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQknA9tTkDL+evPDi7yX8mtVVN2LK0EEXI7ZYA788BAPteSIRPVEAu1PCCxtJIz2yrOljXfn X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 12/02/2013 09:26, Stefano Lattarini wrote: >> Given that 1.12.0 was "not really final release", >> > Why not? AM_PROG_MKDIR_P. > This is true, but is only due to the fact that I released them with > too much haste, without giving time for proper testing. IOW, this > debacle has been a fault of mine, not of the naming scheme. True, but it shows a pattern: most people (even developers who get involved in the process, such as Paolo) do not even look at the beta versions.. > I don't see any need for this; everyone knows that a new major release > is more likely to contain bugs and rough edges. (OTOH, this is not > excuse to be sloppy and hastily in the release process as I've been > for 1.13; but avoiding repeating the mistake in the future will only > require more care and attention from the maintainer, and not a change > of policy). True, but a new beta also is also more likely to contain bugs and rough edges... so it's basically the same thing, thus why I'm saying that it should just be the same. Put out the new major at "not stable yet", try it out all around, then make a release to call it stable. > Any link about this? The info I found on Google doesn't seem very > helpful nor relevant. I'm afraid I don't have anything that Google wouldn't have. But at least for 2.2, it was declared stable much later than ".0" if I'm not mistaken. Basically, it would be like making policy that the new major branch is not stable until we say it is.. which is really what we need. -- Diego Elio Pettenò — Flameeyes flameeyes@flameeyes.eu — http://blog.flameeyes.eu/ From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Daniel Herring Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 16:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136068701129345 (code B ref 13578); Tue, 12 Feb 2013 16:37:02 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 16:36:51 +0000 Received: from localhost ([127.0.0.1]:52386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Iqg-0007dF-R1 for submit@debbugs.gnu.org; Tue, 12 Feb 2013 11:36:51 -0500 Received: from caiajhbdcaid.dreamhost.com ([208.97.132.83]:38664 helo=homiemail-a20.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Iqe-0007d8-JV for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 11:36:50 -0500 Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 673E27EC072; Tue, 12 Feb 2013 08:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tentpost.com; h=date:from :to:subject:in-reply-to:message-id:references:mime-version: content-type; s=tentpost.com; bh=XQz174cc1BNZ+Bp5vY/U77jz3j8=; b=haWznPMW0NjnfQXz7f8zCS7at6KBxSM6FhYGev1o+wTm5Vakb2hQMBpWnbFPj divnXPdhkBNXv8PJjAZwOYOvYb3Qi00nZUa7tnGc149HHAmRcdZ6hAIGrnOCtp/D yvb4etToN2QKrSKhE6c0BkXsv82mKwwG2/E2H6ihX6Nho0= Received: from strider2.home (pool-173-48-243-37.bstnma.fios.verizon.net [173.48.243.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dherring@tentpost.com) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id EDF957EC063; Tue, 12 Feb 2013 08:36:20 -0800 (PST) Date: Tue, 12 Feb 2013 11:36:20 -0500 (EST) From: Daniel Herring X-X-Sender: nuntius@strider2.example.org In-Reply-To: <511A5C77.9080904@flameeyes.eu> Message-ID: References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <51190792.9070902@flameeyes.eu> <5119FC99.30706@gmail.com> <511A5C77.9080904@flameeyes.eu> User-Agent: Alpine 2.02 (LNX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) I like the -alpha/-beta/-rcN markings. As someone who often tracks cutting-edge stuff, it is nice to have a clear indicator of how stable the author things something is. This info helps the user do a quick cost/benefit estimate when deciding what version to use today. - Daniel From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 16:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Cc: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136068748830012 (code B ref 13578); Tue, 12 Feb 2013 16:45:01 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 16:44:48 +0000 Received: from localhost ([127.0.0.1]:52392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5IyO-0007o1-0u for submit@debbugs.gnu.org; Tue, 12 Feb 2013 11:44:48 -0500 Received: from mail-ea0-f178.google.com ([209.85.215.178]:47663) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5IyL-0007ns-69 for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 11:44:46 -0500 Received: by mail-ea0-f178.google.com with SMTP id a14so134245eaa.37 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 08:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rzKlQTxamfJ29pfXWwr5EuaRe2x8y0nohFVfUvj+NIs=; b=v65IO1SCVFx7HPCZu6tSj1t2MpE5h/C2FxQ31vtnJ0wDpysng68TbVu5C1rAAp8Dls UCyIC6/+XtQgIiQ4W3SATWNR1EjxeU5rOwFFe8B73wAtJLqWQxzFqzUhiEnCcDSX2QH1 Fe6f3IC5GuOW4JvEMBkJa35QjY/XAcO9rCe9hV2wT1z1F45/fVXU7w15J+F1/vgWss3V Mw5lYgoA5JbputBE1uFGD10XXSdJMet73KPUFUvVYS1YaggWmmuqxP9qLYlSx4+N14Nc yShAYV9jnrhJDtlv8R0HBxODvpXgubrPtycsic+lqAJqpARpmiiF8Y8mnzh46GRLXz+N 77cA== X-Received: by 10.14.182.137 with SMTP id o9mr28915398eem.13.1360687457969; Tue, 12 Feb 2013 08:44:17 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id s3sm30382314eem.4.2013.02.12.08.44.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:44:17 -0800 (PST) Message-ID: <511A7156.2000706@gmail.com> Date: Tue, 12 Feb 2013 17:44:06 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <51190792.9070902@flameeyes.eu> <5119FC99.30706@gmail.com> <511A5C77.9080904@flameeyes.eu> In-Reply-To: <511A5C77.9080904@flameeyes.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/12/2013 04:15 PM, Diego Elio Pettenò wrote: > On 12/02/2013 09:26, Stefano Lattarini wrote: >>> Given that 1.12.0 was "not really final release", >>> >> Why not? > > AM_PROG_MKDIR_P. > Ah, right. I had forgot about that (selective memory? A dangerous thing). >> This is true, but is only due to the fact that I released them with >> too much haste, without giving time for proper testing. IOW, this >> debacle has been a fault of mine, not of the naming scheme. > > True, but it shows a pattern: most people (even developers who get > involved in the process, such as Paolo) do not even look at the beta > versions.. > That is not something automake can do anything about. Releasing beta versions whose version numbers suggests they are actually stable versions is a solution worse than the problem. But you might correctly point out that, due to lack of proper testing, this is already what we are doing right now (albeit not by choice); so the issue becomes at this point a documentation issue (that is, we should find a way to inform the users that early stable versions of new major releases might turn out to be lamentably unstable in practice, if nobody has given the betas proper testing). See again below. >> I don't see any need for this; everyone knows that a new major release >> is more likely to contain bugs and rough edges. (OTOH, this is not >> excuse to be sloppy and hastily in the release process as I've been >> for 1.13; but avoiding repeating the mistake in the future will only >> require more care and attention from the maintainer, and not a change >> of policy). > > True, but a new beta also is also more likely to contain bugs and rough > edges... so it's basically the same thing, thus why I'm saying that it > should just be the same. Put out the new major at "not stable yet", try > it out all around, then make a release to call it stable. > This sounds sensible, but I think it should be done in addition to the usual release of "classic" beta versions (with the hope that someone will get to testing them eventually). And if we agree on this approach, the only required change would be a new section about this versioning and stability issues in the Automake manual (and/or in the Autotools Mythbuster guide). As usual, patches are welcome (this is not really my itch). >> Any link about this? The info I found on Google doesn't seem very >> helpful nor relevant. > > I'm afraid I don't have anything that Google wouldn't have. But at least > for 2.2, it was declared stable much later than ".0" if I'm not > mistaken. > That happened with Python as well, and I guess with many other softwares who did a major version bump with non-trivial backward incompatibilities. > Basically, it would be like making policy that the new major > branch is not stable until we say it is.. which is really what we need. > Ah, ok, so in the end you already agree that this is a "documentation" issue rather than a versioning one. Please correct me if I'm wrong! Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Vincent Torri Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 16:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org, Jack Kelly , Miles Bader Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136068787930585 (code B ref 13578); Tue, 12 Feb 2013 16:52:02 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 16:51:19 +0000 Received: from localhost ([127.0.0.1]:52397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5J4g-0007xG-Sr for submit@debbugs.gnu.org; Tue, 12 Feb 2013 11:51:19 -0500 Received: from mail-la0-f52.google.com ([209.85.215.52]:52226) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5BS5-0004Ad-Ij for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 03:42:59 -0500 Received: by mail-la0-f52.google.com with SMTP id fs12so6515667lab.25 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 00:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aSFP89c7FTOVbJaJrqiYgAzTQUvSYw3UkVZ9Y1PuAn0=; b=RgHPWBo0a5PB8SIMSaTNCa40LF7NVIynEIe9yB6CyyJP1ZU+tyhWWCkN0UzK29F8zi XbEGAqEzn26oV4AnoQ9MbThlYKhX1DvGr1Lb99Pwh6/eI38Pq6lwog986frjxPSqXTeB VQFRXawk7wvtoSztedbOlKTl2AYGtc25kqZm3VjgCoq6QWY6bTL4C6ka218NZbcHd3Sr Dsy2BYId3pVgq5RSa1v7x8pnLnkiyfCHFhawTd/OmHQhIZybnMeLcw0W4S98htOxhQwJ voIMG+005TlUO6E4+RTJgOwmCPsBbC85zT7obxrHJxGysPKchJnft1Um1Q2D2yj/l6Yw qZiQ== MIME-Version: 1.0 X-Received: by 10.152.144.71 with SMTP id sk7mr15756767lab.29.1360658551943; Tue, 12 Feb 2013 00:42:31 -0800 (PST) Received: by 10.112.59.33 with HTTP; Tue, 12 Feb 2013 00:42:31 -0800 (PST) In-Reply-To: <5119FF6B.80707@gmail.com> References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <87ehgmpfz0.fsf@catnip.gol.com> <5119F7F1.3010001@gmail.com> <5119FF6B.80707@gmail.com> Date: Tue, 12 Feb 2013 09:42:31 +0100 Message-ID: From: Vincent Torri Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Mailman-Approved-At: Tue, 12 Feb 2013 11:51:17 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini wrote: > On 02/12/2013 09:25 AM, Miles Bader wrote: >> 2013/2/12 Stefano Lattarini : >>>>> But what if we want to have multiple betas for, say, Automake 1.14? Today, >>>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme >>>>> you are proposing? >>>> >>>> There's always 1.14.0.1, ... >>>> >>> Yuck; the new versioning scheme is done exactly to avoid that kind >>> of overly long version numbers >> >> Well, I agree in general that too many components is yucky, but keep >> in mind that these _aren't releases_, so assigning them "awkward" >> version numbers doesn't really seem all that annoying. These really >> aren't part of the historical record. The existing naming scheme for >> betas does the same thing (uses "weird" version numbers), but is >> problematic because it's not mechanically consistent with "ordinary" >> version numbers (and so screws up cases such as packaging software). >> > Mostly fair points; but the biggest issue with this proposal (not > sure why I didn't think of it before, sorry) is that it is not at > all clear that a version like "1.13.0.1" is supposed to be a beta > release. People will easily mistake it for a stable release. OK, > we can add warnings and info and whatnot in the manual and homepage > of automake about our unusual versioning scheme, but how many people > will read them? And in the end, even those who do will likely be > just annoyed by the fact that we are trying to be clever and invent > a new versioining scheme incompatible with every other existing one. > > No, if we want to change the versioning scheme for beta and rc > versions, we want the new scheme to be already used and well known. in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for beta and release candidate. It's sufficiently explicit. For example, 1.14.0_beta Vincent Torri From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 12 Feb 2013 17:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13606914667055 (code B ref 13578); Tue, 12 Feb 2013 17:52:01 +0000 Received: (at 13578) by debbugs.gnu.org; 12 Feb 2013 17:51:06 +0000 Received: from localhost ([127.0.0.1]:52501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5K0X-0001pj-Ml for submit@debbugs.gnu.org; Tue, 12 Feb 2013 12:51:05 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:58241) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5K0W-0001pd-7B for 13578@debbugs.gnu.org; Tue, 12 Feb 2013 12:51:05 -0500 Received: by mail-ea0-f172.google.com with SMTP id f13so159268eaa.31 for <13578@debbugs.gnu.org>; Tue, 12 Feb 2013 09:50:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=nEdgCQfCAklYAAOhmeJnNeRHymCfLR2/lHVEZ0XZ0Dc=; b=BVG6YMeqHodV80sfgbJ5jwIOIrlCbE6QiTnHGKuUycCCAzVnrMrMH+cO3L/vSLSGOM 9gCnSgrmTOIPoAKTEnc0+h9tqrCV32k562nyy1P1RpSzOQeNrYjxr+h5OrJBgQrUTULp rlS9COAAykcP2A3w7h6XlyVsszYLacWpyefMEmkl79Sa7kO/IJ2rPl62ohhorg9vG6P4 O93lTzhn3gyw2X/tlVjao2nXpVe7AZRAahxnbEuSJj9DM1fXSHnja2oOBNz49XOIPLnO frRCiB0d6xo3uxdc1ewmMs1Unry2Vi7joC+MJP/LJLfJEkJW3EYKJikTfEifZbyFxuLB ESxA== X-Received: by 10.14.204.195 with SMTP id h43mr12449696eeo.14.1360691436548; Tue, 12 Feb 2013 09:50:36 -0800 (PST) Received: from saladin.home.flameeyes.eu (adsl-ull-109-154.49-151.net24.it. [151.49.154.109]) by mx.google.com with ESMTPS id 3sm69045821eej.6.2013.02.12.09.50.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 09:50:34 -0800 (PST) Message-ID: <511A80E5.60309@flameeyes.eu> Date: Tue, 12 Feb 2013 18:50:29 +0100 From: Diego Elio =?UTF-8?Q?Petten=C3=B2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <51190792.9070902@flameeyes.eu> <5119FC99.30706@gmail.com> <511A5C77.9080904@flameeyes.eu> <511A7156.2000706@gmail.com> In-Reply-To: <511A7156.2000706@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnxSNDnqOgN45MH4FwuuOZd28Q1soWJBTwKiltmQ8TsqM/X+ddS+iVxjCcE1KS8gddo3jPI X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 12/02/2013 17:44, Stefano Lattarini wrote: > Ah, ok, so in the end you already agree that this is a "documentation" > issue rather than a versioning one. Please correct me if I'm wrong! I guess it's a matter of perception. I honestly don't see the point of beta software if nobody's using it, as it would just actually be an alpha for the beta (.0/.1 releases) which then becomes stable (.2+ — sometimes). If we go with a new major version we could have: 2.0.x -> new major, testing branch (let's not call it beta!), all fine but it throws a huge warning at runtime that the branch is not finalized yet and thus that it should not be used for distributed software 2.1.x -> new major, stable branch, micro versions for bugfix only 2.2.x -> new major, new features branch, introduces deprecation warnings for features leaving in 3.0, possibly some opt-in versions of features becoming standard in 3.0. _If needed_ only: 2.90.x -> experimental branch for the upcoming 3.0 testing branch -- Diego Elio Pettenò — Flameeyes flameeyes@flameeyes.eu — http://blog.flameeyes.eu/ From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 13 Feb 2013 18:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Diego Elio =?UTF-8?Q?Petten=C3=B2?= Cc: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136077965124674 (code B ref 13578); Wed, 13 Feb 2013 18:21:01 +0000 Received: (at 13578) by debbugs.gnu.org; 13 Feb 2013 18:20:51 +0000 Received: from localhost ([127.0.0.1]:54503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5gwt-0006Pv-Bm for submit@debbugs.gnu.org; Wed, 13 Feb 2013 13:20:51 -0500 Received: from mail-ee0-f45.google.com ([74.125.83.45]:36221) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5gws-0006Pq-0j for 13578@debbugs.gnu.org; Wed, 13 Feb 2013 13:20:50 -0500 Received: by mail-ee0-f45.google.com with SMTP id b57so804722eek.4 for <13578@debbugs.gnu.org>; Wed, 13 Feb 2013 10:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KthLdRd5jDsbplsvaZUrSTmLFduV0sAaKPDouAaKnN8=; b=N5WSkfIxu2trPP02vPdUR9iOFro+jmqzg1Xs5u9CYnYbXrYGe3ZYByhYg5Ne5yO8d+ 5nGqDgl3Kt1J3YYVxnYG600yGa4Lu4YJzjoRAYn1j5WB/0+lBLoAjHc2Mvk4aNmfWDrE /9ueU8/bRp/i5zdeD0jwqZjmr1HR2IlTGwVo+Aa+an6NJ683Q4ACrmMhlb12hEPdpZ4Z RaYetF5uBqm7jGJF/FZ3hbzsas3xPO/T/kOiExNoP5NokiazI2sqqIrRMNHj67cZCep1 x0TCdUXTtjdd1SOHwsjLZAfOJ86COTPipcYc9HDXK7zJwn54xs1E0nb3IbcPzYzb4l6q Ml1Q== X-Received: by 10.14.209.131 with SMTP id s3mr76976002eeo.26.1360779616471; Wed, 13 Feb 2013 10:20:16 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id q5sm74542618eeo.17.2013.02.13.10.20.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 10:20:15 -0800 (PST) Message-ID: <511BD956.3070409@gmail.com> Date: Wed, 13 Feb 2013 19:20:06 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <510A5980.7010801@flameeyes.eu> <510A67F5.5020904@gmail.com> <510A869C.4010104@flameeyes.eu> <87622dxgyx.fsf@jackkelly.name> <510B07C8.2070108@flameeyes.eu> <87wquswpoj.fsf@jackkelly.name> <51190641.2080803@gmail.com> <51190792.9070902@flameeyes.eu> <5119FC99.30706@gmail.com> <511A5C77.9080904@flameeyes.eu> <511A7156.2000706@gmail.com> <511A80E5.60309@flameeyes.eu> In-Reply-To: <511A80E5.60309@flameeyes.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Diego. On 02/12/2013 06:50 PM, Diego Elio Pettenò wrote: > On 12/02/2013 17:44, Stefano Lattarini wrote: >> Ah, ok, so in the end you already agree that this is a "documentation" >> issue rather than a versioning one. Please correct me if I'm wrong! > > I guess it's a matter of perception. > > I honestly don't see the point of beta software if nobody's using it, as > it would just actually be an alpha for the beta (.0/.1 releases) which > then becomes stable (.2+ — sometimes). > > If we go with a new major version we could have: > > 2.0.x -> new major, testing branch (let's not call it beta!), all fine > but it throws a huge warning at runtime that the branch is not finalized > yet and thus that it should not be used for distributed software > > 2.1.x -> new major, stable branch, micro versions for bugfix only > > 2.2.x -> new major, new features branch, introduces deprecation warnings > for features leaving in 3.0, possibly some opt-in versions of features > becoming standard in 3.0. > > _If needed_ only: > > 2.90.x -> experimental branch for the upcoming 3.0 testing branch > The scheme you are proposing seems sensible to me. Anyway, it is an *extension* to my new proposed versioning/branching scheme, so we don't have to decide on its adoption right away -- we can switch to my proposed scheme first, and then refine/enhance it with your proposal, if nobody objects. OK? Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 13 Feb 2013 18:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136078081126467 (code B ref 13578); Wed, 13 Feb 2013 18:41:01 +0000 Received: (at 13578) by debbugs.gnu.org; 13 Feb 2013 18:40:11 +0000 Received: from localhost ([127.0.0.1]:54519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5hFZ-0006so-5X for submit@debbugs.gnu.org; Wed, 13 Feb 2013 13:40:10 -0500 Received: from mail-ea0-f180.google.com ([209.85.215.180]:45571) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5hFU-0006se-Mn for 13578@debbugs.gnu.org; Wed, 13 Feb 2013 13:40:07 -0500 Received: by mail-ea0-f180.google.com with SMTP id c1so576456eaa.25 for <13578@debbugs.gnu.org>; Wed, 13 Feb 2013 10:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2TU7tng99bvQ2WaXzrUhy0Ttj4MZfs8IeNaNu106sN8=; b=Y4Vj4glsYvrIhhq+BbCtE3LTTe9PYgmIhAKEaFVuDbxqpNGT0oP5Do/931cskKjGub bAvSR19R37FpBfPxi7cunzgzBg2zJINOm8Nn8wjjcMs8S+iM3R0daOXlZKPWX+XVg1m1 MD9XKeZ6hPn9EhP5SdXMZmJxr/yzuuCv+Np1Ply1B7CuhunzItZAcJy99BQdKuggh9aq XrB8hoinlDd+RG35UV5bmg6zHPDF3XajzX9Phx5GGyaZhidT7Y2/QMHqk8HX2ew+C1J1 A9fyuBbjUlArdcG4e83AZb4Qp822U1da0Phoed+4KoQ4rcnE/A4b6NMgq4WK0oAFRD+B M93g== X-Received: by 10.14.202.71 with SMTP id c47mr19315090eeo.39.1360780771405; Wed, 13 Feb 2013 10:39:31 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id l8sm40583519een.10.2013.02.13.10.39.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 10:39:30 -0800 (PST) Message-ID: <511BDDDD.2040904@gmail.com> Date: Wed, 13 Feb 2013 19:39:25 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> In-Reply-To: <5106D62B.6070007@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Reference: On 01/28/2013 08:48 PM, Stefano Lattarini wrote: > Severity: wishlist > > Recently, the need of a quick bug-fixing release 1.13.2 has shown some > issues with the current branching and versioning scheme of Automake. > > Let's first see some background, to better understand the situation. > > Given the typically long time between a major release 1.N and the next > one 1.(N+1) (say, 1.11 and 1.12), I had begun, in the last year or so, > to introduce some (mostly) safe and backward-compatible but non-trivial > changes and enhancements between a minor release 1.N.M and the next one > 1.N.(M+1) (say, 1.12.1 and 1.12.2). > > As an example of such changes, in the NEWS entry for 1.12.2 we have: > > - Recursive cleaning rules descends into the $(SUBDIRS) in the natural > order (as done by the other recursive rules), rather than in the > inverse order. They used to do that in order to work a round a > limitation in an older implementation of the automatic dependency > tracking support, but that limitation had been lifted years ago > already, when the automatic dependency tracking based on side-effects > of compilation had been introduced. > > And in the NEWS entry for 1.11.3 we have: > > - For programs and libraries, automake now detects EXTRA_foo_DEPENDENCIES > and adds them to the normal list of dependencies, but without > overwriting the foo_DEPENDENCIES variable, which is normally computed > by automake. > > - "make dist" can now create lzip-compressed tarballs. > > This approach has however shown several drawbacks since its introduction: > > * Such changes might be not trivial, and their correct implementation > and testing can leave the maint branch in a non-safely-releasable > state, thus complicating the cut of a urgent bug-fixing release. > > * Given the current maint/master branching scheme, the sudden need > of such a release forces us to mess with the planned version numbers > and the branching setup, since we might not be able to cut such > a release from maint (as that might already contain some changes we > consider inappropriate for a mere bug-fixing release). > > * Some bug-fixes (especially for for old bugs) or code clean-ups and > refactorings (especially for old or complex code) might cause > backward-incompatible changes in the semantics of some corner-case > behaviours; that can unpleasantly surprise users who are thinking > they are getting only basic bug-fixes, and get instead bitten by an > unexpected behavioural change. Such users might rightfully complain > that, while they approve the change and are well ready to adapt > their packages to it, they don't expect to be forced to do so when > upgrading to a mere minor release. See for example: > http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html > > So I propose the following change in the Automake versioning scheme: > > * Major releases should actually have the major version number bumped. > That is, the next major Automake version will be 2.0, rather than > 1.14; and the major version after that will be 3.0; and so on. > After all, there is no shortage of integer numbers to use :-) > Such major releases can introduce backward-incompatibilities (albeit > such incompatibilities should be announced well in advance, and a > smooth transition plan prepared for them), and try more risking > and daring refactorings. > > * Minor releases have the minor version number bumped (1.13 -> 1.14 > -> 1.15 ...), can introduce new "safe" features, do non-trivial > but mostly safe code clean-ups, and even add new runtime warnings > (rigorously non-fatal); but they shouldn't include any backward > incompatible change, nor contain any potentially destabilizing > refactoring or sweeping change, nor introduce new features whose > implementation might be liable to cause bugs or regressions in > existing code. > > * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing > releases; no new features should be added, and ideally, only > trivial bugs, recent regressions, or documentation issues should > be addressed here. > > Another plus of this new versioning scheme is that it will allow > different minor releases, even with the same major version, to > co-exist on the same system (that's because the $(APIVERSION) > variable will get bumped with each minor version now). > > I also propose the following change to the branching scheme currently > implemented in the Automake Git repository: > > * The 'maint' branch will be reserved to cut of the next micro > release; so it will just see fixes for regressions, trivial > bugs, or documentation issues, and no "active" development > whatsoever. > > * The 'master' branch will be where the development of the next > minor release will take place; that is, a sort of "middle-ground" > between the roles so far fulfilled by the 'maint' and 'master' > branches in the current branching scheme. > > * The (new) 'next' branch will be reserved for the development > of the next major release; it will basically take over the rule > that is currently fulfilled by the 'master' branch. > > * 'maint' will be kept regularly merged into 'master', and > 'master' into 'next' (and 'next' into the 'ng/master', which > is where the Automake-NG codebase currently live). > > * Feature branches should typically be based off of 'master', > and we can decide later whether to eventually merge them into > 'master' or into 'next'. > > * None of 'maint', 'master' and 'next' should be rewindable. > > If you agree with my proposal, I think the new schemes could be > implemented right after the 1.13.2 release; so that the planned > Automake 1.13.3 will be released as 1.14, and the planned Automake > 1.14 will be released as Automake 2.0. > > And of course, we'll have to publicize the new versioning scheme > ASAP, and with quite high visibility. I propose the following > avenues: > > - A news item in the savannah AUtomake page; > - A message to autotools-announce; > - An entry in the NEWS file of 1.13.2. > - ??? (suggestions welcome) > > -*-*- > > Feedback, opinions, objections? > > Regards, > Stefano > OK, so far I've seen only positive feedback about this proposal. There are still some unresolved issues about how to handle beta releases; but the related proposals can be seen as a refinement of my scheme, not as something incompatible or in competition with it. So I see no reason to hold back the implementation of my proposal on their account: we can implement those refinements later, once some consensus is reached and the details are worked out. So, if I see no further objections, I'm going ahead with my proposal in a few days. Thanks, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Sun, 17 Feb 2013 14:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136111314129552 (code B ref 13578); Sun, 17 Feb 2013 14:59:02 +0000 Received: (at 13578) by debbugs.gnu.org; 17 Feb 2013 14:59:01 +0000 Received: from localhost ([127.0.0.1]:33158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U75hh-0007gX-O2 for submit@debbugs.gnu.org; Sun, 17 Feb 2013 09:58:59 -0500 Received: from mail-ee0-f53.google.com ([74.125.83.53]:63961) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U75hc-0007gM-3o for 13578@debbugs.gnu.org; Sun, 17 Feb 2013 09:58:55 -0500 Received: by mail-ee0-f53.google.com with SMTP id e53so2545011eek.40 for <13578@debbugs.gnu.org>; Sun, 17 Feb 2013 06:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=I/X0gGwD4X5uIAVWVonmPtBtCK4Y6FZGGwHWkxBOQtU=; b=dMaUQpEpK1VZJzU+AmDCOqG+51/Hw9LzF9zELrmBBPL8pVtOiR2yLHoNK4TmtqHXLg LJaYRfHq4G/Ld7IPTk1aX34mqU8LnUCxIGuz8i/Z28O3rfpPstbxr52CxEuDesxZ7rkI Zdh8cgib97NvgEyQbhgF/ywjpsrZVQVqo6yKcsempzQuvuGFGcLlt3vKgHzlAY6R/9Yw EXa35lHu4zRNGaRVa4v4K8sAv3ceDBid0h6aYEIAKlRyLcLwUFPDptD+8C1Ad/iCPbyZ X5T9maNCRvU3TiHiSo/5quhlbajlrKCx11/9i8bD1XdEvvLRHXCeHHzm/TdGmNNX4fVM 6eBw== X-Received: by 10.14.193.134 with SMTP id k6mr33167185een.37.1361113076674; Sun, 17 Feb 2013 06:57:56 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id 3sm93665045eej.6.2013.02.17.06.57.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 06:57:55 -0800 (PST) Message-ID: <5120EFE9.30200@gmail.com> Date: Sun, 17 Feb 2013 15:57:45 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> In-Reply-To: <511BDDDD.2040904@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/13/2013 07:39 PM, Stefano Lattarini wrote: > > Reference: > > > OK, so far I've seen only positive feedback about this proposal. There > are still some unresolved issues about how to handle beta releases; but > the related proposals can be seen as a refinement of my scheme, not as > something incompatible or in competition with it. So I see no reason > to hold back the implementation of my proposal on their account: we can > implement those refinements later, once some consensus is reached and > the details are worked out. > > So, if I see no further objections, I'm going ahead with my proposal in > a few days. > Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Thanks, Stefano ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- >From 97aaf121e92767dc06385d020dd30cdfaa86126f Mon Sep 17 00:00:00 2001 Message-Id: <97aaf121e92767dc06385d020dd30cdfaa86126f.1361111789.git.stefano.lattarini@gmail.com> From: Stefano Lattarini Date: Sun, 17 Feb 2013 10:25:29 +0100 Subject: [PATCH] describe new versioning and branching scheme, and adjust to it See discussion about automake bug#13578 for more details and background. Basically, for the versioning scheme: - micro versions only for bug and regression fixing; - minor versions for new backward-compatible features, and new non-fatal deprecations; - major versions for backward-incompatibilities, complex new features, and major refactoring. And for the git branching scheme: + branch 'next' is for the upcoming major version; + branch 'master' is now for the upcoming minor version; + branch 'maint' is for the upcoming micro (bug-fixing) version; + the merging hierarchy is: 'maint' -> 'master' -> 'next'. * HACKING (Automake versioning and compatibility scheme): New. (Working with git): Adjust. * NEWS: Update and fix. * aclocal.in: Adjust some "FIXME" messages. * automake.in: Likewise. * m4/mkdirp.m4: Likewise. * t/aclocal-acdir.sh: Likewise. * t/aclocal-macrodir.tap: Likewise. * t/aclocal-macrodirs.tap: Likewise. * lib/Automake/Options.pm: Likewise. * m4/internal/ac-config-macro-dirs.m4: Likewise. Signed-off-by: Stefano Lattarini --- HACKING | 100 +++++++++++++++++++++++++++++------- NEWS | 59 +++++++++++++++++---- aclocal.in | 8 +-- automake.in | 12 +++-- lib/Automake/Options.pm | 4 +- m4/internal/ac-config-macro-dirs.m4 | 2 +- m4/mkdirp.m4 | 3 +- t/aclocal-acdir.sh | 2 +- t/aclocal-macrodir.tap | 2 +- t/aclocal-macrodirs.tap | 2 +- 10 files changed, 150 insertions(+), 44 deletions(-) diff --git a/HACKING b/HACKING index c70143e..604bf67 100644 --- a/HACKING +++ b/HACKING @@ -93,6 +93,48 @@ code without. ============================================================================ += Automake versioning and compatibility scheme + +* There are three kinds of automake releases: + + - new major releases (e.g., 2.0, 5.0) + - new minor releases (e.g., 1.14, 2.1) + - micro a.k.a. "bug-fixing" releases (e.g., 1.13.2, 2.0.1, 3.5.17). + + A new major release should have the major version number bumped, and + the minor and micro version numbers reset to zero. A new minor release + should have the major version number unchanged, the minor version number + bumped, and the micro version number reset to zero. Finally, a new + micro version should have the major and minor version numbers unchanged, + and the micro version number bumped. + + For example, the first minor version after 1.13.2 will be 1.14; the + first bug-fixing version after 1.14 that will be 1.14.1; the first + new major version after all such releases will be 2.0; the first + bug-fixing version after 2.0 will be 2.0.1; and a further bug-fixing + version after 2.0.1 will be 2.0.2. + +* Micro releases should be just bug-fixing releases; no new features + should be added, and ideally, only trivial bugs, recent regressions, + or documentation issues should be addressed by them. + +* Minor releases can introduce new "safe" features, do non-trivial + but mostly safe code clean-ups, and even add new runtime warnings + (rigorously non-fatal); but they shouldn't include any backward + incompatible change, nor contain any potentially destabilizing + refactoring or sweeping change, nor introduce new features whose + implementation might be liable to cause bugs or regressions in + existing code. + +* Major releases can introduce backward-incompatibilities (albeit + such incompatibilities should be announced well in advance, and + a smooth transition plan prepared for them), and try more risking + and daring refactorings and code cleanups. + +* For more information, refer to the extensive discussion associated + with automake bug#13578. + +============================================================================ = Working with git * To regenerate dependent files created by aclocal and automake, @@ -103,22 +145,43 @@ latest stable version of Autoconf installed and available early in your PATH. -* The Automake git tree currently carries two basic branches: 'master' for - the current development, and 'maint' for maintenance and bug fixes. The - maint branch should be kept regularly merged into the master branch. - It is advisable to merge only after a set of related commits have been - applied, to avoid introducing too much noise in the history. +* The Automake git tree currently carries three basic branches: 'maint', + 'master' and 'next'. + +* The 'maint' branch, reserved to changes that should go into the next + micro release; so it will just see fixes for regressions, trivial + bugs, or documentation issues, and no "active" development whatsoever. + Since emergency regression-fixing or security releases could be cut + from this branch at any time, it should always be kept in a releasable + state. + +* The 'master' branch is where the development of the next minor release + takes place. It should be kept in a stable, almost-releasable state, + to simplify testing and deploying of new minor version. Note that + this is not a hard rule, and such "stability" is not expected to be + absolute (emergency releases are cut from maint anyway). + +* The 'next' branch is reserved for the development of the next major + release. Experimenting a little here is OK, but don't let the branch + grow too unstable; if you need to do exploratory programming + or over-arching change, you should use a dedicated topic branch, and + only merge that back once it is reasonably stable. + +* The 'maint' branch should be kept regularly merged into the 'master' + branch, and the 'master' branch into the 'next' branch. It is advisable + to merge only after a set of related commits have been applied, to avoid + introducing too much noise in the history. * There may be a number of longer-lived feature branches for new developments. They should be based off of a common ancestor of all active branches to which the feature should or might be merged later. - in the future, we might introduce a special branch named 'next' that - may serve as common ground for feature merging and testing, should - they not yet be ready for master. -* After a major release is done, the master branch is to be merged into - the maint branch, and then a "new" master branch created stemming - from the resulting commit. +* After a new minor release is done, the 'master' branch is to be merged + into the 'maint' branch, and then a "new" 'master' branch created + stemming from the resulting commit. + Similarly, after a new major release is done, the 'next' branch is to + be merged into both the 'master' and 'maint' branch, and then "new" + 'master' and 'next' branches created stemming from the resulting commit. * When fixing a bug (especially a long-standing one), it may be useful to commit the fix to a new temporary branch based off the commit that @@ -126,15 +189,14 @@ the active branches descending from the buggy commit. This offers a simple way to fix the bug consistently and effectively. -* For merges from branches other than maint, prefer 'git merge --log' over - plain 'git merge', so that a later 'git log' gives an indication of which - actual patches were merged even when they don't appear early in the list. +* For merges, prefer 'git merge --log' over plain 'git merge', so that + a later 'git log' gives an indication of which actual patches were + merged even when they don't appear early in the list. -* master and release branches should not be rewound, i.e., should always - fast-forward, except maybe for privacy issues. The maint branch should not - be rewound except maybe after retiring a release branch or a new stable - release. For next, and for feature branches, the announcement for the - branch should document rewinding policy. +* The 'next', 'master' and 'maint' branches should not be rewound, i.e., + should always fast-forward, except maybe for privacy issues. For + feature branches, the announcement for the branch should document + the rewinding policy. ============================================================================ = Writing a good commit message diff --git a/NEWS b/NEWS index f9a1fb1..1ea9fa6 100644 --- a/NEWS +++ b/NEWS @@ -1,22 +1,59 @@ -New in 1.13.2: +* WARNING: New versioning scheme for Automake. + + - Starting with this version onward, Automake will use an update and + more rational versioning scheme, one that will allow users to know + which kind of changes can be expected from a new version, based on + its version number. + + + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only + documentation updates and bug and regression fixes; they will + not introduce new features, nor any backward-incompatibility (any + such incompatibility would be considered a bug, to be fixed with + a further micro release). + + + Minor versions (e.g., 1.14, 2.1) can introduce new backward + compatible features; the only backward-incompatibilities allowed + in such a release are new *non-fatal* deprecations and warnings, + and possibly fixes for old or non-trivial bugs (or even inefficient + behaviours) that could unfortunately have been seen, and used, by + some developers as "corner case features". This kind of fixes + should hopefully be quite rare. + + + Major versions (now expected to be released every 18 or 24 months, + and not more often) can introduce new big features (possibly with + rough edges and not-fully-stabilized APIs), removal of deprecated + features, backward-incompatible changes of behaviour, and possibly + major refactorings (that, while ideally transparent to the user, + could introduce new bugs). Incompatibilities should however not + be introduced gratuitously and abruptly; a proper deprecation path + should be duly implemented in the preceding minor releases. + + - According to this new scheme, the next major version of Automake + (the one that has until now been labelled as '1.14') will actually + become "Automake 2.0". Automake 1.14 will be the next minor version, + which will introduce new features and deprecation, but no backward + incompatibility. + + - See discussion about automake bug#13578 for more details and + background: * WARNING: Future backward-incompatibilities! - - Automake 1.14 will require Autoconf 2.70 or later (which is still + - Automake 2.0 will require Autoconf 2.70 or later (which is still unreleased at the moment of writing, but is planned to be released - before Automake 1.14 is). + before Automake 2.0 is). - - Automake 1.14 will drop support for the long-deprecated 'configure.in' + - Automake 2.0 will drop support for the long-deprecated 'configure.in' name for the Autoconf input file. You are advised to start using the recommended name 'configure.ac' instead, ASAP. - The ACLOCAL_AMFLAGS special make variable will be fully deprecated - in Automake 1.14 (where it will raise warnings in the "obsolete" + in Automake 2.0 (where it will raise warnings in the "obsolete" category). You are advised to start relying on the new Automake support for AC_CONFIG_MACRO_DIRS instead (which was introduced in Automake 1.13). - - Automake 1.14 will remove support for automatic dependency tracking + - Automake 2.0 will remove support for automatic dependency tracking with the SGI C/C++ compilers on IRIX. The SGI depmode has been reported broken "in the wild" already, and we don't think investing time in debugging and fixing is worthwhile, especially considering @@ -30,16 +67,20 @@ New in 1.13.2: modern Windows versions will continue to be fully supported. - Automake-provided scripts and makefile recipes might (finally!) - start assuming a POSIX shell in Automake 1.14. + start assuming a POSIX shell in Automake 2.0. - - Starting from Automake 1.14, third-party m4 files located in the + - Starting from Automake 2.0, third-party m4 files located in the system-wide aclocal directory, as well as in any directory listed in the ACLOCAL_PATH environment variable, will take precedence over "built-in" Automake macros. For example (assuming Automake is installed in the /usr/local hierarchy), a definition of the AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4' should take precedence over the same-named automake-provided macro - (defined in '/usr/local/share/aclocal-1.14/vala.m4'). + (defined in '/usr/local/share/aclocal-2.0/vala.m4'). + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New in 1.13.2: * Obsolescent features: diff --git a/aclocal.in b/aclocal.in index b51c09d..82e9031 100644 --- a/aclocal.in +++ b/aclocal.in @@ -47,7 +47,7 @@ use File::Path (); # Some globals. # Support AC_CONFIG_MACRO_DIRS also with older autoconf. -# FIXME: To be removed in Automake 1.14, once we can assume autoconf +# FIXME: To be removed in Automake 2.0, once we can assume autoconf # 2.70 or later. # FIXME: keep in sync with 'internal/ac-config-macro-dirs.m4'. my $ac_config_macro_dirs_fallback = @@ -744,7 +744,7 @@ sub trace_used_macros () # a bug in option parsing code of autom4te 2.68 and earlier will cause # it to read standard input last, even if the "-" argument is specified # early. - # FIXME: To be removed in Automake 1.14, once we can assume autoconf + # FIXME: To be removed in Automake 2.0, once we can assume autoconf # 2.70 or later. $traces .= "$automake_includes[0]/internal/ac-config-macro-dirs.m4 "; @@ -763,7 +763,7 @@ sub trace_used_macros () 'AC_CONFIG_MACRO_DIR_TRACE', # FIXME: Tracing the next two macros is a hack for # compatibility with older autoconf. Remove this in - # Automake 1.14, when we can assume Autoconf 2.70 or + # Automake 2.0, when we can assume Autoconf 2.70 or # later. 'AC_CONFIG_MACRO_DIR', '_AM_CONFIG_MACRO_DIRS')), @@ -820,7 +820,7 @@ sub trace_used_macros () # FIXME: in Autoconf >= 2.70, AC_CONFIG_MACRO_DIR calls # AC_CONFIG_MACRO_DIR_TRACE behind the scenes, which could # leave unwanted duplicates in @ac_config_macro_dirs. - # Remove this in Automake 1.14, when we'll stop tracing + # Remove this in Automake 2.0, when we'll stop tracing # AC_CONFIG_MACRO_DIR explicitly. @ac_config_macro_dirs = uniq @ac_config_macro_dirs; diff --git a/automake.in b/automake.in index 9ed3507..0c2ab3d 100644 --- a/automake.in +++ b/automake.in @@ -2131,7 +2131,7 @@ sub handle_source_transform ($$$$%) msg_var ('unsupported', $ext_var, $ext_var->name . " can assume at most one value") if $default_source_ext =~ /[\t ]/; (my $default_source = $unxformed) =~ s,(\.[^./\\]*)?$,$default_source_ext,; - # TODO: Remove this backward-compatibility hack in Automake 1.14. + # TODO: Remove this backward-compatibility hack in Automake 2.0. if ($old_default_source ne $default_source && !$ext_var && (rule $old_default_source @@ -4146,8 +4146,8 @@ sub handle_configure ($$$@) # Distribute and define mkinstalldirs only if it is already present # in the package, for backward compatibility (some people may still # use $(mkinstalldirs)). - # TODO: start warning about this in Automake 1.13.2, and have - # TODO: Automake 1.14 or 1.15 drop it (and the mkinstalldirs script + # TODO: start warning about this in Automake 1.14, and have + # TODO: Automake 2.0 drop it (and the mkinstalldirs script # TODO: as well). my $mkidpath = "$config_aux_dir/mkinstalldirs"; if (-f $mkidpath) @@ -5144,7 +5144,7 @@ sub scan_autoconf_traces ($) AC_REQUIRE_AUX_FILE => 1, AC_SUBST_TRACE => 1, AM_AUTOMAKE_VERSION => 1, - AM_PROG_MKDIR_P => 0, # FIXME: to be removed in 1.14 + AM_PROG_MKDIR_P => 0, AM_CONDITIONAL => 2, AM_EXTRA_RECURSIVE_TARGETS => 1, AM_GNU_GETTEXT => 0, @@ -5300,8 +5300,10 @@ sub scan_autoconf_traces ($) $seen_automake_version = 1; } - elsif ($macro eq 'AM_PROG_MKDIR_P') # FIXME: to be removed in 1.14 + elsif ($macro eq 'AM_PROG_MKDIR_P') { + # FIXME: we are no longer going to remove this! adjust warning + # FIXME: message accordingly. msg 'obsolete', $where, <<'EOF'; The 'AM_PROG_MKDIR_P' macro is deprecated, and will soon be removed. You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead, diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm index 3674920..cfeb78e 100644 --- a/lib/Automake/Options.pm +++ b/lib/Automake/Options.pm @@ -315,7 +315,7 @@ sub _process_option_list (\%@) { set_strictness ($_); } - # TODO: Remove this special check in Automake 1.14 or 1.15. + # TODO: Remove this special check in Automake 3.0. elsif (/^(.*\/)?ansi2knr$/) { # Obsolete (and now removed) de-ANSI-fication support. @@ -327,7 +327,7 @@ sub _process_option_list (\%@) { error $where, "support for Cygnus-style trees has been removed"; } - # TODO: Remove this special check in Automake 1.14 or 1.15. + # TODO: Remove this special check in Automake 3.0. elsif ($_ eq 'dist-lzma') { error ($where, "support for lzma-compressed distribution " . diff --git a/m4/internal/ac-config-macro-dirs.m4 b/m4/internal/ac-config-macro-dirs.m4 index 4ddcef3..2684883 100644 --- a/m4/internal/ac-config-macro-dirs.m4 +++ b/m4/internal/ac-config-macro-dirs.m4 @@ -1,5 +1,5 @@ # Support AC_CONFIG_MACRO_DIRS with older autoconf. -*- Autoconf -*- -# FIXME: To be removed in Automake 1.14, once we can assume autoconf +# FIXME: To be removed in Automake 2.0, once we can assume autoconf # 2.70 or later. # FIXME: keep in sync with the contents of the variable # '$ac_config_macro_dirs_fallback' in aclocal.in. diff --git a/m4/mkdirp.m4 b/m4/mkdirp.m4 index 68f44cb..0b90d2c 100644 --- a/m4/mkdirp.m4 +++ b/m4/mkdirp.m4 @@ -11,7 +11,8 @@ AC_DEFUN([AM_PROG_MKDIR_P], [AC_PREREQ([2.60])dnl AC_REQUIRE([AC_PROG_MKDIR_P])dnl -dnl FIXME to be removed in Automake 1.14. +dnl FIXME we are no longer going to remove this! adjust warning +dnl FIXME message accordingly. AC_DIAGNOSE([obsolete], [$0: this macro is deprecated, and will soon be removed. You should use the Autoconf-provided 'AC][_PROG_MKDIR_P' macro instead, diff --git a/t/aclocal-acdir.sh b/t/aclocal-acdir.sh index 7fbb27a..80eba31 100755 --- a/t/aclocal-acdir.sh +++ b/t/aclocal-acdir.sh @@ -21,7 +21,7 @@ . test-init.sh mkdir am sys -# FIXME: remove in Automake 1.14. +# FIXME: remove in Automake 2.0 mkdir am/internal : > am/internal/ac-config-macro-dirs.m4 diff --git a/t/aclocal-macrodir.tap b/t/aclocal-macrodir.tap index 3c66e53..44af05f 100755 --- a/t/aclocal-macrodir.tap +++ b/t/aclocal-macrodir.tap @@ -174,7 +174,7 @@ test_end #--------------------------------------------------------------------------- # Avoid spurious failures with pre-2.70 autoconf. -# FIXME: remove this in automake 1.14, once we require Autoconf 2.70. +# FIXME: remove this in automake 2.0, once we require Autoconf 2.70. if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then test_begin "AC_CONFIG_MACRO_DIR interaction with AC_REQUIRE" diff --git a/t/aclocal-macrodirs.tap b/t/aclocal-macrodirs.tap index 89e424d..ac594bb 100755 --- a/t/aclocal-macrodirs.tap +++ b/t/aclocal-macrodirs.tap @@ -373,7 +373,7 @@ test_end #--------------------------------------------------------------------------- # Avoid spurious failures with pre-2.70 autoconf. -# FIXME: remove this in automake 1.14, once we require Autoconf 2.70. +# FIXME: remove this in automake 2.0, once we require Autoconf 2.70. if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then test_begin "AC_CONFIG_MACRO_DIRS interaction with AC_REQUIRE" -- 1.8.1.1.701.g02339dd From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 21 Feb 2013 14:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13614572337946 (code B ref 13578); Thu, 21 Feb 2013 14:34:02 +0000 Received: (at 13578) by debbugs.gnu.org; 21 Feb 2013 14:33:53 +0000 Received: from localhost ([127.0.0.1]:41832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8XDa-000245-TZ for submit@debbugs.gnu.org; Thu, 21 Feb 2013 09:33:52 -0500 Received: from mail-ee0-f53.google.com ([74.125.83.53]:45353) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8XDL-00023j-Bw for 13578@debbugs.gnu.org; Thu, 21 Feb 2013 09:33:43 -0500 Received: by mail-ee0-f53.google.com with SMTP id e53so4596579eek.26 for <13578@debbugs.gnu.org>; Thu, 21 Feb 2013 06:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8H5yYXyxEWrvLNh0jlBuYP5o4D0jUG8/W1MGd7mhN0Q=; b=gM6y0vLF+ktsVPFFhV2Pyr5068RwjbOke1iCZV3NGGmSaJsFqOR7ZhdYsVBGKvckgZ R12NQvJt+YR2JjLC+QL8KAFxDbF+19TlhGZxqI+rp1Z/gGok2ng6DZUY1ha7Lnrgn/Dv KrS5sVpqjyhN9pBNg4GqPJj3Tfp3cLtB9hEuhtuaqcopkIvvXAWUPnU9PRn6ZBaSMh1S k68AziuYx1GIOBcRKcS4/tJTYTGFG558PfgPwe+Lsxi8Rdlm8ZIMNvhGS2GRHRA2uEVD XvuHlZz+YEMzfookStqs6Sn5Ivcs8DPNf9we8Tue8aVF3fN9vQHr86HSIjNATi7RhFpF giSQ== X-Received: by 10.14.182.137 with SMTP id o9mr81020628eem.13.1361457137545; Thu, 21 Feb 2013 06:32:17 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id s3sm44820726eem.4.2013.02.21.06.32.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 06:32:16 -0800 (PST) Message-ID: <51262FEE.5030509@gmail.com> Date: Thu, 21 Feb 2013 15:32:14 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> In-Reply-To: <5120EFE9.30200@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) On 02/17/2013 03:57 PM, Stefano Lattarini wrote: > On 02/13/2013 07:39 PM, Stefano Lattarini wrote: >> >> Reference: >> >> >> OK, so far I've seen only positive feedback about this proposal. There >> are still some unresolved issues about how to handle beta releases; but >> the related proposals can be seen as a refinement of my scheme, not as >> something incompatible or in competition with it. So I see no reason >> to hold back the implementation of my proposal on their account: we can >> implement those refinements later, once some consensus is reached and >> the details are worked out. >> >> So, if I see no further objections, I'm going ahead with my proposal in >> a few days. >> > Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as > well as few miscellaneous comments in tests and scripts). Then we can > finally proceed with the re-shuffling of the Git repository -- which I > guess will also have to be announced in autotools-announce at least, as > well as reported as a news on Savannah. > > So here is my attempt; OK to push to branch-1.13.2? I will proceed in a > couple of days if there is no objection. > Pushed now. Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 21 Feb 2013 15:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136145928811550 (code B ref 13578); Thu, 21 Feb 2013 15:09:01 +0000 Received: (at 13578) by debbugs.gnu.org; 21 Feb 2013 15:08:08 +0000 Received: from localhost ([127.0.0.1]:42579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8Xkl-00030F-JY for submit@debbugs.gnu.org; Thu, 21 Feb 2013 10:08:08 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:46822) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8Xki-0002zw-DQ for 13578@debbugs.gnu.org; Thu, 21 Feb 2013 10:08:06 -0500 Received: by mail-ea0-f172.google.com with SMTP id f13so4016138eaa.31 for <13578@debbugs.gnu.org>; Thu, 21 Feb 2013 07:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dgWCCQohkRAQ78jI4FaAt4ZojARvayEZIJlcQcScghA=; b=qs/hmxuz4mRW7E3uhri3SxMVl35ui/yncX8471e8Q9CvaHt8xMfGri56G3O9uiYVGz tbiqdhQi6Iianz8X7TC1GyU4EvpvCkVIWgkqttGrHop9ny4xVPW9Wz0kKAq7T+2q60uT WucSb/ld96BcyXbqeG3dGj4PkUDyMelQl3ts6W7qYZQcgAVcuN3QovWx6ISx6pbL3el0 rxkDlp4cmweBpsLAWQ0bOULfGYLMPgoQBtcJC0AveWqoLZRBgcihn/l/+2XoAhfcBVzn 0h2P2k9AgdZWDL5ZIDzx/BynjEgxGYMy9/3JAIPkl2idwG8BjBY1Mc7HwCrkGaWzDyrk ZmBg== X-Received: by 10.14.183.67 with SMTP id p43mr81319657eem.10.1361459206440; Thu, 21 Feb 2013 07:06:46 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id m46sm51398057eeo.16.2013.02.21.07.06.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:06:45 -0800 (PST) Message-ID: <51263803.6020605@gmail.com> Date: Thu, 21 Feb 2013 16:06:43 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> In-Reply-To: <51262FEE.5030509@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/21/2013 03:32 PM, Stefano Lattarini wrote: >> Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as >> well as few miscellaneous comments in tests and scripts). Then we can >> finally proceed with the re-shuffling of the Git repository -- which I >> guess will also have to be announced in autotools-announce at least, as >> well as reported as a news on Savannah. >> >> So here is my attempt; OK to push to branch-1.13.2? I will proceed in a >> couple of days if there is no objection. >> > Pushed now. > And here is the follow-up to fix some left-over references to the older versioning scheme in 'maint' (they were not present in 'branch-1.13.2'). Already pushed to 'maint'. In a couple of days, I will proceed with this "branch moving": * branch-1.13.2 -> maint * maint -> master * master -> next Regards, Stefano ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- >From d5f83b89cc4d2da9078669018877b3bac5c2fadc Mon Sep 17 00:00:00 2001 Message-Id: From: Stefano Lattarini Date: Thu, 21 Feb 2013 15:52:22 +0100 Subject: [PATCH] maint: more adjustments to the new versioning scheme This is a follow-up to commit 'v1.13.1b-11-g97aaf12'. * automake.in: Adjust a comment. * PLANS: Adjust several files in here. Signed-off-by: Stefano Lattarini --- PLANS/obsolete-removed/am-prog-mkdir-p.txt | 8 +++----- PLANS/obsolete-removed/configure.in.txt | 10 +++++----- PLANS/rm-f-without-args.txt | 10 +++++----- PLANS/subdir-objects.txt | 10 +++++----- PLANS/texi/drop-split-info-files.txt | 6 +++--- automake.in | 2 +- 6 files changed, 22 insertions(+), 24 deletions(-) diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt b/PLANS/obsolete-removed/am-prog-mkdir-p.txt index d5b7695..20d5cf5 100644 --- a/PLANS/obsolete-removed/am-prog-mkdir-p.txt +++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt @@ -1,6 +1,4 @@ -The macro AM_PROG_MKDIR_P is no longer going to be removed in Automake 1.14 -(and in fact, any plan to remove it "evenatually" has been dropped as well). - +The macro AM_PROG_MKDIR_P is no longer going to be removed from Automake. Let's see a bit of history to understand why. I had already scheduled the removal of the long-deprecated AM_PROG_MKDR_P @@ -46,14 +44,14 @@ out, and we lose. That already happened in practice: Moreover, while I might see it as not unreasonable to ask a developer -using Automake 1.14 to also update Gettext to 1.18.2, that would not +using Automake 2.0 to also update Gettext to 1.18.2, that would not be enough; in order for gettext to use the correct data files, that developer would have to update his configure.ac to read: AM_GNU_GETTEXT_VERSION([0.18.2]) thus requiring *all* of his co-developers to install Gettext 1.18.2, -even if they are still using, say, Automake 1.13. Bad. +even if they are still using, say, Automake 1.13 or 1.14. Bad. So I decided to re-instate this macro as a simple alias for AC_PROG_MKDIR_P (plus a non-fatal runtime warning in the 'obsolete' category), and drop diff --git a/PLANS/obsolete-removed/configure.in.txt b/PLANS/obsolete-removed/configure.in.txt index baed853..180f92c 100644 --- a/PLANS/obsolete-removed/configure.in.txt +++ b/PLANS/obsolete-removed/configure.in.txt @@ -13,16 +13,16 @@ present in the development version of autoconf so far (scheduled to become Autoconf 2.70). So ... -For Automake 1.14 ------------------ +For Automake 2.0 +---------------- ... we have decided to wait until 2.70 is out before really removing 'configure.in' support. Since we plan to require Autoconf 2.70 in -Automake 1.14 (so that we can remove the hacky code emulating +Automake 2.0 (so that we can remove the hacky code emulating AC_CONFIG_MACRO_DIRS for older autoconf versions), we are quite sure that Autoconf will actually have started deprecating 'configure.in' -by the time Automake 1.14 is released. +by the time Automake 2.0 is released. Note that the removal of 'configure.in' has already been implemented -in our master branch (from where the 1.14 release will be finally +in our 'next' branch (from where the 2.0 release will be finally cut); see commits 'v1.13-17-gbff57c8' and 'v1.13-21-g7626e63'. diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt index 5362f98..918e049 100644 --- a/PLANS/rm-f-without-args.txt +++ b/PLANS/rm-f-without-args.txt @@ -21,20 +21,20 @@ the no-args "rm -f" usage is supported on the system configure is being run on; complain loudly if this is not the case, and tell the user to report the situation to us. -For Automake 1.14 ------------------ +For Automake 2.0 +---------------- Make any failure in the configure-time probe check introduced by the previous point fatal; and in case of failure, also suggest to the user to install an older version of GNU coreutils to work around the limitation of his system (this version should be old enough not to -be bootstrapped with Automake 1.14, otherwise the user will face a +be bootstrapped with Automake 2.0, otherwise the user will face a bootstrapping catch-22). In all our recipes, start assuming "rm -f" with no argument is OK; simplify and de-uglify the recipes accordingly. -For Automake 1.15 ------------------ +For Automake 3.0 +---------------- Remove the runtime probe altogether. diff --git a/PLANS/subdir-objects.txt b/PLANS/subdir-objects.txt index e4e6e25..8647403 100644 --- a/PLANS/subdir-objects.txt +++ b/PLANS/subdir-objects.txt @@ -2,7 +2,7 @@ Summary ------- We want to make the behaviour currently enabled by the 'subdir-objects' -the default one, and in fact the *only* one, in Automake 1.14. +the default one, and in fact the *only* one, in Automake 2.0. See automake bug#13378: . Details @@ -38,8 +38,8 @@ C compilation rules mistakenly passed the "-c -o" options combination unconditionally (even to losing compiler) when the 'subdir-objects' was used but sources were only present in the top-level directory. -TODO for automake 1.13.2 ------------------------- +TODO for automake 1.14 +---------------------- Give a warning in the category 'unsupported' if the 'subdir-objects' option is not specified. This should give the users enough forewarning @@ -50,8 +50,8 @@ Be sure to avoid the warning when it would be irrelevant, i.e., if all source files sit in "current" directory (thanks to Peter Johansson for suggesting this). -For automake 1.14 ------------------ +For automake 2.0 +---------------- Remove the copy & paste of Autoconf internals in our AC_PROG_CC rewrite See the first patch in the series: diff --git a/PLANS/texi/drop-split-info-files.txt b/PLANS/texi/drop-split-info-files.txt index 7084331..8b36ecb 100644 --- a/PLANS/texi/drop-split-info-files.txt +++ b/PLANS/texi/drop-split-info-files.txt @@ -1,7 +1,7 @@ -For automake 1.14 ------------------ +For automake 2.0 +---------------- -We want to drop split info files in Automake 1.14. +We want to drop split info files in Automake 2.0. See automake bug#13351: . Basically, it has been confirmed that the original reason behind diff --git a/automake.in b/automake.in index 44d67b4..13811f7 100644 --- a/automake.in +++ b/automake.in @@ -1711,7 +1711,7 @@ sub handle_single_transform ($$$$$%) } else { - # Since the next major version of automake (1.14) will + # Since the next major version of automake (2.0) will # make the behaviour so far only activated with the # 'subdir-object' option mandatory, it's better if we # start warning users not using that option. -- 1.8.1.1.754.gb3600c3 From unknown Sun Jun 22 08:00:12 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Stefano Lattarini Subject: bug#13578: closed ([IMPORTANT] *Implemented* a new versioning scheme for automake releases, and a new branching scheme for the Git repository) Message-ID: References: <5129007E.3050609@gmail.com> <5106D62B.6070007@gmail.com> X-Gnu-PR-Message: they-closed 13578 X-Gnu-PR-Package: automake Reply-To: 13578@debbugs.gnu.org Date: Sat, 23 Feb 2013 17:49:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1361641743-22901-1" This is a multi-part message in MIME format... ------------=_1361641743-22901-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #13578: A new versioning scheme for automake releases, and a new branching = scheme for the Git repository which was filed against the automake package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 13578@debbugs.gnu.org. --=20 13578: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D13578 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1361641743-22901-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 13578-done) by debbugs.gnu.org; 23 Feb 2013 17:48:14 +0000 Received: from localhost ([127.0.0.1]:45944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9JCo-0005w7-4y for submit@debbugs.gnu.org; Sat, 23 Feb 2013 12:48:14 -0500 Received: from mail-we0-f182.google.com ([74.125.82.182]:64602) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9JCl-0005vy-GK for 13578-done@debbugs.gnu.org; Sat, 23 Feb 2013 12:48:12 -0500 Received: by mail-we0-f182.google.com with SMTP id t57so1412600wey.13 for <13578-done@debbugs.gnu.org>; Sat, 23 Feb 2013 09:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6bIWg5lqeXbqV71fs13ufmF76MqlEty5EBXO7njr3uI=; b=hAt5Ve6KWbNheGa1uERIGfVlSU/Dagyr5ze+RxO3xXcW4gfQxV7zKtOg9iTUQy+3SA UtsmQZaDvHicX2BHh1AUwLcAJrAIT/9CbG6hX6E90VAzHEsXEoeQeqMbWTqGovo42tJX Ur4tS4ovlT4VdL7icEgNp1ra1g5HhzwAVM/hC079esL2M7JN0woD1/Dq6PxfOYWJJ4Wm K4meibFNGUwvGwDLvGmuVF4UKMF0NjrX4qftCn+WY98+lh+Ul30N/guvSBIUHijxfeGQ cl14J+oVnekQHtfQnW7fPvtCnQA9DB2wJ6GmrarnWGDLrOZxv7yrsGTeSYzpVeQs+XA2 f2EQ== X-Received: by 10.180.102.201 with SMTP id fq9mr3570105wib.2.1361641601529; Sat, 23 Feb 2013 09:46:41 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id du2sm4743010wib.0.2013.02.23.09.46.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 09:46:40 -0800 (PST) Message-ID: <5129007E.3050609@gmail.com> Date: Sat, 23 Feb 2013 18:46:38 +0100 From: Stefano Lattarini MIME-Version: 1.0 To: automake@gnu.org, 13578-done@debbugs.gnu.org Subject: [IMPORTANT] *Implemented* a new versioning scheme for automake releases, and a new branching scheme for the Git repository References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> In-Reply-To: <51263803.6020605@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13578-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) On 02/21/2013 04:06 PM, Stefano Lattarini wrote: > > On 02/21/2013 03:32 PM, Stefano Lattarini wrote: >> >>> Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as >>> well as few miscellaneous comments in tests and scripts). Then we can >>> finally proceed with the re-shuffling of the Git repository -- which I >>> guess will also have to be announced in autotools-announce at least, as >>> well as reported as a news on Savannah. >>> >>> So here is my attempt; OK to push to branch-1.13.2? I will proceed in a >>> couple of days if there is no objection. >>> >> Pushed now. >> > In a couple of days, I will proceed with this "branch moving": > > * branch-1.13.2 -> maint > * maint -> master > * master -> next > Done. I'm thus closing this bug report. Note that there are still some pending, tentative proposals about how to improve the names and release policy for beta versions; but since those proposals are more a follow-up to this discussion than an integral part of it, they are IMO more suited to be further discussed in new, dedicated threads. So, if anyone is still interested in pursuing those ideas, please open a new bug report (preferably complete with references to the relevant messages in this thread, and with a summary of the main ideas, motivations, and consensus -- or lack thereof -- reached so far). Thanks to all that have participated to this discussion, and offered their feedback, ideas and experiences. Best regards, Stefano ------------=_1361641743-22901-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 28 Jan 2013 19:49:56 +0000 Received: from localhost ([127.0.0.1]:52905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzuiJ-0001qk-JS for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44792) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzuiG-0001qb-Gs for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tzuhl-0004ko-Ps for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:25 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:59722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tzuhl-0004ke-NK for submit@debbugs.gnu.org; Mon, 28 Jan 2013 14:49:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tzuhk-000772-3W for bug-automake@gnu.org; Mon, 28 Jan 2013 14:49:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tzuhi-0004j7-9P for bug-automake@gnu.org; Mon, 28 Jan 2013 14:49:19 -0500 Received: from mail-bk0-f43.google.com ([209.85.214.43]:51068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tzuhd-0004i5-EO; Mon, 28 Jan 2013 14:49:13 -0500 Received: by mail-bk0-f43.google.com with SMTP id jm19so1128469bkc.30 for ; Mon, 28 Jan 2013 11:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; bh=8nJoyeA/5FBIa4SiDDrQ6CdzT973tprxeNY55EDkvYw=; b=sZB4yFvSRPHR/nUxHQuSviJ7h1hYYI8vobRLsq9ViDo/yiSAH3T2bD0fwGNGBS7v8U g/efix3xjoVoTi7t7pA2iwNVI9njyaMGPIsc3Vbaxw+QxK2s7UObVskMZEEZ56L77MPE Vd7ZWtR+HtLRGH5oVe6S3lc180f7P/bdIhdzSuc+QaOPTA8/uCFGoA863FNeFyOuJRLS ObB4HVt/Xp2nc8p6w9bndbveYkQJEwu9Fs1uWWO6f+/mju6MUpigpPStDijis454WvVt mo5HqJBcYIhGb83uC+ZTXQ9qDTkrYg2oThLFjrIr9B5SiCkTHgcbTpeirfaHN6Z5MjKM U1Rw== X-Received: by 10.204.132.68 with SMTP id a4mr1944374bkt.42.1359402551836; Mon, 28 Jan 2013 11:49:11 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id hc16sm7373213bkc.2.2013.01.28.11.49.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 11:49:10 -0800 (PST) Message-ID: <5106D62B.6070007@gmail.com> Date: Mon, 28 Jan 2013 20:48:59 +0100 From: Stefano Lattarini MIME-Version: 1.0 To: Automake List , bug-automake@gnu.org Subject: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Severity: wishlist Recently, the need of a quick bug-fixing release 1.13.2 has shown some issues with the current branching and versioning scheme of Automake. Let's first see some background, to better understand the situation. Given the typically long time between a major release 1.N and the next one 1.(N+1) (say, 1.11 and 1.12), I had begun, in the last year or so, to introduce some (mostly) safe and backward-compatible but non-trivial changes and enhancements between a minor release 1.N.M and the next one 1.N.(M+1) (say, 1.12.1 and 1.12.2). As an example of such changes, in the NEWS entry for 1.12.2 we have: - Recursive cleaning rules descends into the $(SUBDIRS) in the natural order (as done by the other recursive rules), rather than in the inverse order. They used to do that in order to work a round a limitation in an older implementation of the automatic dependency tracking support, but that limitation had been lifted years ago already, when the automatic dependency tracking based on side-effects of compilation had been introduced. And in the NEWS entry for 1.11.3 we have: - For programs and libraries, automake now detects EXTRA_foo_DEPENDENCIES and adds them to the normal list of dependencies, but without overwriting the foo_DEPENDENCIES variable, which is normally computed by automake. - "make dist" can now create lzip-compressed tarballs. This approach has however shown several drawbacks since its introduction: * Such changes might be not trivial, and their correct implementation and testing can leave the maint branch in a non-safely-releasable state, thus complicating the cut of a urgent bug-fixing release. * Given the current maint/master branching scheme, the sudden need of such a release forces us to mess with the planned version numbers and the branching setup, since we might not be able to cut such a release from maint (as that might already contain some changes we consider inappropriate for a mere bug-fixing release). * Some bug-fixes (especially for for old bugs) or code clean-ups and refactorings (especially for old or complex code) might cause backward-incompatible changes in the semantics of some corner-case behaviours; that can unpleasantly surprise users who are thinking they are getting only basic bug-fixes, and get instead bitten by an unexpected behavioural change. Such users might rightfully complain that, while they approve the change and are well ready to adapt their packages to it, they don't expect to be forced to do so when upgrading to a mere minor release. See for example: http://lists.gnu.org/archive/html/bug-automake/2012-07/msg00107.html So I propose the following change in the Automake versioning scheme: * Major releases should actually have the major version number bumped. That is, the next major Automake version will be 2.0, rather than 1.14; and the major version after that will be 3.0; and so on. After all, there is no shortage of integer numbers to use :-) Such major releases can introduce backward-incompatibilities (albeit such incompatibilities should be announced well in advance, and a smooth transition plan prepared for them), and try more risking and daring refactorings. * Minor releases have the minor version number bumped (1.13 -> 1.14 -> 1.15 ...), can introduce new "safe" features, do non-trivial but mostly safe code clean-ups, and even add new runtime warnings (rigorously non-fatal); but they shouldn't include any backward incompatible change, nor contain any potentially destabilizing refactoring or sweeping change, nor introduce new features whose implementation might be liable to cause bugs or regressions in existing code. * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing releases; no new features should be added, and ideally, only trivial bugs, recent regressions, or documentation issues should be addressed here. Another plus of this new versioning scheme is that it will allow different minor releases, even with the same major version, to co-exist on the same system (that's because the $(APIVERSION) variable will get bumped with each minor version now). I also propose the following change to the branching scheme currently implemented in the Automake Git repository: * The 'maint' branch will be reserved to cut of the next micro release; so it will just see fixes for regressions, trivial bugs, or documentation issues, and no "active" development whatsoever. * The 'master' branch will be where the development of the next minor release will take place; that is, a sort of "middle-ground" between the roles so far fulfilled by the 'maint' and 'master' branches in the current branching scheme. * The (new) 'next' branch will be reserved for the development of the next major release; it will basically take over the rule that is currently fulfilled by the 'master' branch. * 'maint' will be kept regularly merged into 'master', and 'master' into 'next' (and 'next' into the 'ng/master', which is where the Automake-NG codebase currently live). * Feature branches should typically be based off of 'master', and we can decide later whether to eventually merge them into 'master' or into 'next'. * None of 'maint', 'master' and 'next' should be rewindable. If you agree with my proposal, I think the new schemes could be implemented right after the 1.13.2 release; so that the planned Automake 1.13.3 will be released as 1.14, and the planned Automake 1.14 will be released as Automake 2.0. And of course, we'll have to publicize the new versioning scheme ASAP, and with quite high visibility. I propose the following avenues: - A news item in the savannah AUtomake page; - A message to autotools-announce; - An entry in the NEWS file of 1.13.2. - ??? (suggestions welcome) -*-*- Feedback, opinions, objections? Regards, Stefano ------------=_1361641743-22901-1-- From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Sat, 23 Feb 2013 18:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136164286924505 (code B ref 13578); Sat, 23 Feb 2013 18:08:02 +0000 Received: (at 13578) by debbugs.gnu.org; 23 Feb 2013 18:07:49 +0000 Received: from localhost ([127.0.0.1]:45968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9JVl-0006NB-A8 for submit@debbugs.gnu.org; Sat, 23 Feb 2013 13:07:49 -0500 Received: from mail-wg0-f44.google.com ([74.125.82.44]:58472) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9JVj-0006N3-5F for 13578@debbugs.gnu.org; Sat, 23 Feb 2013 13:07:48 -0500 Received: by mail-wg0-f44.google.com with SMTP id dr12so1367768wgb.35 for <13578@debbugs.gnu.org>; Sat, 23 Feb 2013 10:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AY/xHhAsQwR6jxJz+hvBJ3vj+nUQBy+HgQAI7B5IR4E=; b=uUorjTz8zpE3RdJhl95qkiuf8OZKqt8CpHSoE6nFtcSauF1hpWJlJSdQCBgVSoHg3c XMZS/sbLUd+VTGkMjmcqBBjqNWdV9hM2XQvnYJN3378wrIMBumKM98P4MNOFsjXGAzlr v5JKhmTWdto4vEmU/oKUxtyvO6m222NCR2KjDB953gxjtRxSiuJgw5ufBIZQpkGVQTdI Q9DavMskzz2ukKbzSu1+1jqmZQbvGF5Jm1UVoB7XFxUd/aBlAI1ZojMWx8AbJ6BRLnrU j8SiKPiCSqMVefjqbMQ8yhacXH5ybRn7Cj3CMZY21MmOFCwuyfKpuICMjnbTT6Ew7Rec /fZA== X-Received: by 10.180.105.232 with SMTP id gp8mr3501241wib.33.1361642777512; Sat, 23 Feb 2013 10:06:17 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id j4sm4786528wiz.10.2013.02.23.10.06.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 10:06:16 -0800 (PST) Message-ID: <51290516.2080607@gmail.com> Date: Sat, 23 Feb 2013 19:06:14 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> In-Reply-To: <5129007E.3050609@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) On 02/23/2013 06:46 PM, Stefano Lattarini wrote: > On 02/21/2013 04:06 PM, Stefano Lattarini wrote: >> >> On 02/21/2013 03:32 PM, Stefano Lattarini wrote: >>> >>>> Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as >>>> well as few miscellaneous comments in tests and scripts). Then we can >>>> finally proceed with the re-shuffling of the Git repository -- which I >>>> guess will also have to be announced in autotools-announce at least, as >>>> well as reported as a news on Savannah. >>>> >>>> So here is my attempt; OK to push to branch-1.13.2? I will proceed in a >>>> couple of days if there is no objection. >>>> >>> Pushed now. >>> >> In a couple of days, I will proceed with this "branch moving": >> >> * branch-1.13.2 -> maint >> * maint -> master >> * master -> next >> > Done. > Damn, not really. For some questionable reason, Savannah is rejecting my non-fast-forward push to master even if I specify '--force', and I cannot use the usual trick "delete the remote branch, then push the local one to it" trick that I typically use to work around this problem, since 'master' is the "current branch" of the remote repository, and that cannot be deleted to avoid confusing "git clone". For reference, this is the error message I got when I try to delete master: remote: error: By default, deleting the current branch is denied, because the next remote: error: 'git clone' won't result in any file checked out, causing confusion. remote: error: remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the remote: error: current branch, with or without a warning message. remote: error: remote: error: To squelch this message, you can set it to 'refuse'. remote: error: refusing to delete the current branch: refs/heads/master So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN INCONSISTENT STATE* (not broken, mind you, merely inconsistent with our new declared policies), and should not be used until this issue is resolved. I don't have time to look into this presently, so I'd appreciate if anyone could look into the issue (finding a way not have savannah to reject non-fast-forward pushes would be enough). Thanks, and sorry for the confusion, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Peter Rosin Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 25 Feb 2013 08:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13617801521032 (code B ref 13578); Mon, 25 Feb 2013 08:16:01 +0000 Received: (at 13578) by debbugs.gnu.org; 25 Feb 2013 08:15:52 +0000 Received: from localhost ([127.0.0.1]:48854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9tDz-0000Gb-Oz for submit@debbugs.gnu.org; Mon, 25 Feb 2013 03:15:52 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]:35120) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9tDx-0000GQ-47 for 13578@debbugs.gnu.org; Mon, 25 Feb 2013 03:15:50 -0500 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 03FAD40005; Mon, 25 Feb 2013 09:14:10 +0100 (CET) Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com [90.227.119.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 7CB3C40004; Mon, 25 Feb 2013 09:14:09 +0100 (CET) Message-ID: <512B1D50.5080201@lysator.liu.se> Date: Mon, 25 Feb 2013 09:14:08 +0100 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> In-Reply-To: <51290516.2080607@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 2013-02-23 19:06, Stefano Lattarini wrote: > On 02/23/2013 06:46 PM, Stefano Lattarini wrote: >> On 02/21/2013 04:06 PM, Stefano Lattarini wrote: >>> In a couple of days, I will proceed with this "branch moving": >>> >>> * branch-1.13.2 -> maint >>> * maint -> master >>> * master -> next >>> >> Done. >> > Damn, not really. For some questionable reason, Savannah is rejecting > my non-fast-forward push to master even if I specify '--force', and > I cannot use the usual trick "delete the remote branch, then push the > local one to it" trick that I typically use to work around this > problem, since 'master' is the "current branch" of the remote > repository, and that cannot be deleted to avoid confusing "git clone". I was not aware that those moves would be non-fast-forwards, and I think this is bad bad bad. It's quite hostile to do non-fast-forwards on branches as central as master and maint. And I think git/savannah is rejecting them quite rightly! master and maint have never been published as "rewindable", and it should be correct to base new work on them. They should be left alone, IMHO. You should have implemented this more gradually, such that next would have taken its role directly, but maint and master should have been allowed to grow into the correct branches once the relevant releases had been made. Or even better, implement the change right after a major release so that master and maint would have been correctly positioned from the start. I have a few single-commit local branches that I will simply have to cherry-pick to the new world order. Or is there some better way to move these branches after their base has been pulled from under them? Hopefully there isn't some big chunk of unpublished work that will be killed by these disruptive changes... Cheers, Peter From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 25 Feb 2013 09:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Peter Rosin Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13617839266551 (code B ref 13578); Mon, 25 Feb 2013 09:19:02 +0000 Received: (at 13578) by debbugs.gnu.org; 25 Feb 2013 09:18:46 +0000 Received: from localhost ([127.0.0.1]:48921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9uCq-0001ha-9Y for submit@debbugs.gnu.org; Mon, 25 Feb 2013 04:18:46 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:56239) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9uCn-0001hS-Vx for 13578@debbugs.gnu.org; Mon, 25 Feb 2013 04:18:43 -0500 Received: by mail-ee0-f44.google.com with SMTP id l10so1215515eei.17 for <13578@debbugs.gnu.org>; Mon, 25 Feb 2013 01:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7jeuk6A0OyV9S2kX3BHrV1xSs46O7LsCR6l6p9kczig=; b=e0avToGmsQZMTp5Y3WQEi5N62v/NpPFbHkDz8hq+bJgvUTjktr7ZWOUiiZHkQDbhDt CGWxah6hBStJvlCp0YrDohUsW3MfVJ0+dHQTFvo8LR2ToC5ZpEQG/4Zuo3zwdxs78vMg SnG/++631mfc4+8OqQ9SUzS16zhq4te4awZB2Kb1ucQW1BXqe06VCUFdZ1pCFaleFshG LC+d0c856g3Rv6/OT6++ZTbtM3g3k+yQ4KHfsG2hDqZ7SvnEPVSpuqcf2ACTjDe6Wu7D b8/FOyhJdj3pjhH0uDy3UXzrVJkaXuo28KfqUM23aprUc6wp9qaYT52q2lrVoNWBJ7HG pnqA== X-Received: by 10.14.219.129 with SMTP id m1mr36820408eep.16.1361783822969; Mon, 25 Feb 2013 01:17:02 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id r4sm17178377eeo.12.2013.02.25.01.17.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 01:17:02 -0800 (PST) Message-ID: <512B2C06.6000403@gmail.com> Date: Mon, 25 Feb 2013 10:16:54 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> In-Reply-To: <512B1D50.5080201@lysator.liu.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/25/2013 09:14 AM, Peter Rosin wrote: > On 2013-02-23 19:06, Stefano Lattarini wrote: >> On 02/23/2013 06:46 PM, Stefano Lattarini wrote: >>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote: >>>> In a couple of days, I will proceed with this "branch moving": >>>> >>>> * branch-1.13.2 -> maint >>>> * maint -> master >>>> * master -> next >>>> >>> Done. >>> >> Damn, not really. For some questionable reason, Savannah is rejecting >> my non-fast-forward push to master even if I specify '--force', and >> I cannot use the usual trick "delete the remote branch, then push the >> local one to it" trick that I typically use to work around this >> problem, since 'master' is the "current branch" of the remote >> repository, and that cannot be deleted to avoid confusing "git clone". > > I was not aware that those moves would be non-fast-forwards, and I > think this is bad bad bad. > Note that the users can avoid branch-rewriting issues by renaming their 'master' to 'next' and their 'maint' to 'master' before pulling. This should probably be stated in a message (on list *and* on savannah news) advertising the new versioning and branching scheme (message not yet written; it will be once the current issue is sorted out). > It's quite hostile to do non-fast-forwards > on branches as central as master and maint. And I think git/savannah > is rejecting them quite rightly! > Savannah is rejecting all non-fast-forward pushes (which I find annoying); but it didn't prevent me from deleting and recreating maint, a change that will still appear as a non-fast-forward to any clone of our repository. The reason it doesn't allow me to delete master as well is that doing so would prevent a "git clone" from checking out the sources of a freshly cloned automake, which can be very confusing (and of course, git cannot be aware of the fact that I intend to re-create 'master' just after having deleted it). > master and maint have never been published as "rewindable", and it should > be correct to base new work on them. They should be left alone, IMHO. > Their content has been left alone in fact; it's their "name" that hasn't. > You should have implemented this more gradually, such that next would > have taken its role directly, but maint and master should have been > allowed to grow into the correct branches once the relevant releases had > been made. > This would give a very confusing interim period IMHO. However, note that that we can still implement such a "gentler transition" (for 'master' only) if you really want to, by using a new branch name (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a temporary "alias" to 'next' until the 2.0 release (at which point all of 'maint', 'master' and 'next' will be fast-forwarded to the commit that implements the 2.0 release). I still prefer to pull this sore tooth out right now, though. > Or even better, implement the change right after a major > release so that master and maint would have been correctly positioned > from the start. > > I have a few single-commit local branches that I will simply have to > cherry-pick to the new world order. > No, just rebase them on the new name of the branch they were based on; that is, if they were based on 'master', they are now to be considered based on 'next', if they were based on 'maint', they are now to be considered based on 'master', and if they were based on 'branch-1.13.2' they are not to be considered based on 'maint'. > Or is there some better way to move > these branches after their base has been pulled from under them? > The good thing is that is has not been really pulled away, just *renamed*. Remember that Git branches are just "movable tags" basically, so as long as you have another "handle" referencing the same commit a branch points to (be that a tag or another branch), nothing is lost by removing the branch -- you are just removing a tag, not any "real" content. > Hopefully there isn't some big chunk of unpublished work that will be > killed by these disruptive changes... > No, there is not. As said, no pre-existing commit has been dropped by my planned renames. HTH, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 25 Feb 2013 13:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.1361799746626 (code B ref 13578); Mon, 25 Feb 2013 13:43:02 +0000 Received: (at 13578) by debbugs.gnu.org; 25 Feb 2013 13:42:26 +0000 Received: from localhost ([127.0.0.1]:49116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9yK0-0000A1-KL for submit@debbugs.gnu.org; Mon, 25 Feb 2013 08:42:25 -0500 Received: from mail-ee0-f41.google.com ([74.125.83.41]:64265) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U9yJx-00009t-9a for 13578@debbugs.gnu.org; Mon, 25 Feb 2013 08:42:22 -0500 Received: by mail-ee0-f41.google.com with SMTP id c13so1414906eek.28 for <13578@debbugs.gnu.org>; Mon, 25 Feb 2013 05:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UyNWhYdyjE0QrGqo+NYOKFZU1Mqcalxrg3CbwOZtU0E=; b=Ane5hcjAfSPPy0GGh1ojeE5uIFN+oaYAFm0GjQ0/dtnvdGhR8dWHwp2SBF4hwo4KzG L5QmrLUbmRXYjyHxau2taIsgaWXFQfL3WEbYPLbulJswnOimIBsy7r7qsLzrDbhBA8fA W+YadnE8FRa9ZL2VavebPYkyrzQf+pJeb3d99YEdrye4IxBHClaQYsAR0oquJkjflTk5 ZCIMSmui16SPq4v1IZ+pn6gFHHjRhXfsDWaJwG17J9yVngsPOpuqR6RJJhUBRgFF+61j Buv77woG7rXCxVdvGwDw+2pKH9fKyM1/KGwterp4xdjUomFD4d+45VClrWdeJzohD3w4 MmLQ== X-Received: by 10.14.207.200 with SMTP id n48mr39399559eeo.4.1361799641259; Mon, 25 Feb 2013 05:40:41 -0800 (PST) Received: from [192.168.178.21] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id o3sm18399353eem.15.2013.02.25.05.40.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 05:40:40 -0800 (PST) Message-ID: <512B69D5.9070308@gmail.com> Date: Mon, 25 Feb 2013 14:40:37 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> In-Reply-To: <51290516.2080607@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/23/2013 07:06 PM, Stefano Lattarini wrote: > >>> In a couple of days, I will proceed with this "branch moving": >>> >>> * branch-1.13.2 -> maint >>> * maint -> master >>> * master -> next >>> >> Done. >> > Damn, not really. For some questionable reason, Savannah is rejecting > my non-fast-forward push to master even if I specify '--force', and > I cannot use the usual trick "delete the remote branch, then push the > local one to it" trick that I typically use to work around this > problem, since 'master' is the "current branch" of the remote > repository, and that cannot be deleted to avoid confusing "git clone". > > So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN > INCONSISTENT STATE* (not broken, mind you, merely inconsistent with > our new declared policies), and should not be used until this issue > is resolved. > > I don't have time to look into this presently, > I had time today, so I submitted a Task in the Savannah interface: Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 25 Feb 2013 22:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136183143521239 (code B ref 13578); Mon, 25 Feb 2013 22:31:02 +0000 Received: (at 13578) by debbugs.gnu.org; 25 Feb 2013 22:30:35 +0000 Received: from localhost ([127.0.0.1]:50128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA6Z8-0005WW-KO for submit@debbugs.gnu.org; Mon, 25 Feb 2013 17:30:34 -0500 Received: from smtp11.dentaku.gol.com ([203.216.5.73]:38709) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA6Z5-0005WM-Kf for 13578@debbugs.gnu.org; Mon, 25 Feb 2013 17:30:33 -0500 Received: from 218.33.195.56.eo.eaccess.ne.jp ([218.33.195.56] helo=catnip.gol.com) by smtp11.dentaku.gol.com with esmtpa (Dentaku) (envelope-from ) id 1UA6XP-0005v8-IX; Tue, 26 Feb 2013 07:28:47 +0900 Received: by catnip.gol.com (Postfix, from userid 1000) id D0A86DFC1; Tue, 26 Feb 2013 07:28:45 +0900 (JST) From: Miles Bader References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B69D5.9070308@gmail.com> System-Type: x86_64-unknown-linux-gnu Date: Tue, 26 Feb 2013 07:28:45 +0900 In-Reply-To: <512B69D5.9070308@gmail.com> (Stefano Lattarini's message of "Mon, 25 Feb 2013 14:40:37 +0100") Message-ID: <87wqtwkoyq.fsf@catnip.gol.com> Lines: 32 MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) Stefano Lattarini writes: >>>> * maint -> master >>>> * master -> next >>> >> Damn, not really. For some questionable reason, Savannah is rejecting >> my non-fast-forward push to master even if I specify '--force', and >> I cannot use the usual trick "delete the remote branch, then push the >> local one to it" trick that I typically use to work around this >> problem, since 'master' is the "current branch" of the remote >> repository, and that cannot be deleted to avoid confusing "git clone". >> >> So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN >> INCONSISTENT STATE* (not broken, mind you, merely inconsistent with >> our new declared policies), and should not be used until this issue >> is resolved. >> >> I don't have time to look into this presently, >> > I had time today, so I submitted a Task in the Savannah interface: > What's the point of this renaming, anyway? It doesn't seem to make any functional difference what the names of the branches you use for dev sources and releases are -- and besides being a practical problem, the scheme you've chosen doesn't follow common git practice, so will be surprising/confusing to people... -miles -- You can hack anything you want, with TECO and DDT. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 25 Feb 2013 23:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Miles Bader Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136183375224715 (code B ref 13578); Mon, 25 Feb 2013 23:10:01 +0000 Received: (at 13578) by debbugs.gnu.org; 25 Feb 2013 23:09:12 +0000 Received: from localhost ([127.0.0.1]:50144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA7AV-0006QZ-Da for submit@debbugs.gnu.org; Mon, 25 Feb 2013 18:09:11 -0500 Received: from mail-we0-f173.google.com ([74.125.82.173]:56804) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA7AT-0006QS-0U for 13578@debbugs.gnu.org; Mon, 25 Feb 2013 18:09:10 -0500 Received: by mail-we0-f173.google.com with SMTP id r5so2937577wey.18 for <13578@debbugs.gnu.org>; Mon, 25 Feb 2013 15:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EjCgrvRk+EpRNlv2/+YnpQ9fzTWft2M437BQ2q4BsRE=; b=qO13JapDbFzw8rOwvJqlxERhoEfY/B5ns9c+2nmLJ8yJK6D3Z/RLydb0vC7mHnv4kb K/Mtp2yV+13cGFeG+XuPTAR9+NLz91kVZ7ANTLBnuYuGZfSW01KSNhZIMcI30DenZ8vG yrYVOFMa2D9dGcUd952hrWv0rv3DRbuqxXnPFWycr1M+mmmGXRlSFL7YR3jOQHpC5PKI 7fo23C42Zj73mXYRHFa9OgNc9ajFscyU7fw6ISIvpeQNHPcl37JO9noKYoMJWR0xnrR8 2bA/6DZsaCdDV6on9e0hUj+conYx8A2tyjsjlyKqho967ktZNlAcS0JT58OSqsXANgtC 3Dhw== X-Received: by 10.180.92.129 with SMTP id cm1mr15539295wib.10.1361833646717; Mon, 25 Feb 2013 15:07:26 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id t7sm17908582wiy.2.2013.02.25.15.07.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 15:07:25 -0800 (PST) Message-ID: <512BEEAA.4010106@gmail.com> Date: Tue, 26 Feb 2013 00:07:22 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B69D5.9070308@gmail.com> <87wqtwkoyq.fsf@catnip.gol.com> In-Reply-To: <87wqtwkoyq.fsf@catnip.gol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/25/2013 11:28 PM, Miles Bader wrote: > Stefano Lattarini writes: >>>>> * maint -> master >>>>> * master -> next >>>> >>> Damn, not really. For some questionable reason, Savannah is rejecting >>> my non-fast-forward push to master even if I specify '--force', and >>> I cannot use the usual trick "delete the remote branch, then push the >>> local one to it" trick that I typically use to work around this >>> problem, since 'master' is the "current branch" of the remote >>> repository, and that cannot be deleted to avoid confusing "git clone". >>> >>> So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN >>> INCONSISTENT STATE* (not broken, mind you, merely inconsistent with >>> our new declared policies), and should not be used until this issue >>> is resolved. >>> >>> I don't have time to look into this presently, >>> >> I had time today, so I submitted a Task in the Savannah interface: >> > > What's the point of this renaming, anyway? > The fact that the master branch, being in many ways "the default one" in the Git world, is the one that is most visible and tested; so it should be the one where the future minor releases (that we now pledge to keep backward-compatible) are cut from. > It doesn't seem to make any functional difference what the names of > the branches you use for dev sources and releases are > Functional differences, no, strictly speaking. Yet, when someone clones the Automake repository, he has the 'master' branch checked out automatically (apart for 'bare' clones, where no branch is checked out -- but that is a different usage scenario). And the automated Hydra builder checks the master branch: . And there surely are many other situations where the 'master' branch is handled in special ways, either technically or culturally. -- and besides > being a practical problem, the scheme you've chosen doesn't follow > common git practice, > How so? If you are referring the practice of having 'next' as a test bed for the features to be eventually merged into 'master', note that is not an usual setup, but is only employed by the Git project itself for its own repository; and while I admit it is an intelligent approach that works quite well there, it only does so because of Git's large developer base and very dedicated and very capable maintainer -- things these that Automake lacks at present. > so will be surprising/confusing to people... > Maybe to Git's developers, but I don't see many lurking in here ;-) And anyway, even if that turns out to be the case, the solution would not be to change the new policy for 'master', but to change name to the 'next' branch. And I'm not particularly attached to that name; if anyone wants to suggest a better one, and manage to get a consensus on it, I'm quite ready to rename accordingly. Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Peter Rosin Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 25 Feb 2013 23:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136183650028971 (code B ref 13578); Mon, 25 Feb 2013 23:55:01 +0000 Received: (at 13578) by debbugs.gnu.org; 25 Feb 2013 23:55:00 +0000 Received: from localhost ([127.0.0.1]:50171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA7sq-0007XD-7y for submit@debbugs.gnu.org; Mon, 25 Feb 2013 18:55:00 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]:54173) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA7sl-0007X3-Qo for 13578@debbugs.gnu.org; Mon, 25 Feb 2013 18:54:59 -0500 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CC2D04000E; Tue, 26 Feb 2013 00:53:12 +0100 (CET) Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com [90.227.119.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 3F27040006; Tue, 26 Feb 2013 00:53:12 +0100 (CET) Message-ID: <512BF967.1040701@lysator.liu.se> Date: Tue, 26 Feb 2013 00:53:11 +0100 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> In-Reply-To: <512B2C06.6000403@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 2013-02-25 10:16, Stefano Lattarini wrote: > On 02/25/2013 09:14 AM, Peter Rosin wrote: >> On 2013-02-23 19:06, Stefano Lattarini wrote: >>> On 02/23/2013 06:46 PM, Stefano Lattarini wrote: >>>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote: >>>>> In a couple of days, I will proceed with this "branch moving": >>>>> >>>>> * branch-1.13.2 -> maint >>>>> * maint -> master >>>>> * master -> next >>>>> >>>> Done. >>>> >>> Damn, not really. For some questionable reason, Savannah is rejecting >>> my non-fast-forward push to master even if I specify '--force', and >>> I cannot use the usual trick "delete the remote branch, then push the >>> local one to it" trick that I typically use to work around this >>> problem, since 'master' is the "current branch" of the remote >>> repository, and that cannot be deleted to avoid confusing "git clone". >> >> I was not aware that those moves would be non-fast-forwards, and I >> think this is bad bad bad. >> > Note that the users can avoid branch-rewriting issues by renaming their > 'master' to 'next' and their 'maint' to 'master' before pulling. This > should probably be stated in a message (on list *and* on savannah news) > advertising the new versioning and branching scheme (message not yet > written; it will be once the current issue is sorted out). Hiding stuff like that in some documentation or on a mailing list will not help. You should make it *easy* for people to work on and contribute to automake. Forcing everyone to do a bunch of silly boring renames is not *easy*. It's an obstacle, and obstacles make people nervous and uneasy. Not good, and no, you can't document it away. >> It's quite hostile to do non-fast-forwards >> on branches as central as master and maint. And I think git/savannah >> is rejecting them quite rightly! >> > Savannah is rejecting all non-fast-forward pushes (which I find annoying); > but it didn't prevent me from deleting and recreating maint, a change that > will still appear as a non-fast-forward to any clone of our repository. > > The reason it doesn't allow me to delete master as well is that doing so > would prevent a "git clone" from checking out the sources of a freshly > cloned automake, which can be very confusing (and of course, git cannot > be aware of the fact that I intend to re-create 'master' just after > having deleted it). The reason is irrelevant. non-fast-forwards of central branches is evil. >> master and maint have never been published as "rewindable", and it should >> be correct to base new work on them. They should be left alone, IMHO. >> > Their content has been left alone in fact; it's their "name" that hasn't. > >> You should have implemented this more gradually, such that next would >> have taken its role directly, but maint and master should have been >> allowed to grow into the correct branches once the relevant releases had >> been made. >> > This would give a very confusing interim period IMHO. Yes, confusing. Changes like this cause confusion. > However, note that that we can still implement such a "gentler transition" > (for 'master' only) if you really want to, by using a new branch name > (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a > temporary "alias" to 'next' until the 2.0 release (at which point all of > 'maint', 'master' and 'next' will be fast-forwarded to the commit that > implements the 2.0 release). I still prefer to pull this sore tooth out > right now, though. So messy. >> Or even better, implement the change right after a major >> release so that master and maint would have been correctly positioned >> from the start. >> >> I have a few single-commit local branches that I will simply have to >> cherry-pick to the new world order. >> > No, just rebase them on the new name of the branch they were based on; > that is, if they were based on 'master', they are now to be considered > based on 'next', if they were based on 'maint', they are now to be > considered based on 'master', and if they were based on 'branch-1.13.2' > they are not to be considered based on 'maint'. ( s/are not to/are now to/ ) Yes, that works. But it is a nuisance. >> Or is there some better way to move >> these branches after their base has been pulled from under them? >> > The good thing is that is has not been really pulled away, just *renamed*. > > Remember that Git branches are just "movable tags" basically, so as long > as you have another "handle" referencing the same commit a branch points > to (be that a tag or another branch), nothing is lost by removing the > branch -- you are just removing a tag, not any "real" content. Yes, but the "renames" are extremely surprising to a casual contributor. What if someone has a few commits on, say maint, from before your rename. This someone didn't bother to create a topic branch for these commits for some reason. What happens when those local commits have been forgotten and the new-world-order is pulled? A merge is attempted of the local commits and the whole difference between old and new maint. That is likely to result in a conflict. So, our imaginary dev restores the local maint and puts the local commits on a topic branch and retries only to again see a conflict when the pull is attempted. I bet the poor dev will not first think that upstream has messed up, but that it is some local crap that is happening. How much time will be wasted? BTW, just to test this I did the perfectly valid (no local commits on maint): git checkout maint git pull And my repo is now in a mess with unresolved conflicts. This rename is a mess. It is only clean for you, since it originated from you. Everyone else will have to take about the same manual steps you did in order to follow. Which is crappy and evil and will only work for those of us who pay close attention to the mailing list/docs. The poor sods with a git checkout as of last week but having no reason to pull for some time will wonder what hit them when they actually do pull. Also, git history is fuubared. E.g. commit 0756a43c3a77 "Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint. How confusing is that? >> Hopefully there isn't some big chunk of unpublished work that will be >> killed by these disruptive changes... >> > No, there is not. As said, no pre-existing commit has been dropped by > my planned renames. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 26 Feb 2013 00:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.1361839180626 (code B ref 13578); Tue, 26 Feb 2013 00:40:01 +0000 Received: (at 13578) by debbugs.gnu.org; 26 Feb 2013 00:39:40 +0000 Received: from localhost ([127.0.0.1]:50204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA8a3-0000A2-Qo for submit@debbugs.gnu.org; Mon, 25 Feb 2013 19:39:40 -0500 Received: from mail-qa0-f45.google.com ([209.85.216.45]:57040) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA8a1-00009r-Lk for 13578@debbugs.gnu.org; Mon, 25 Feb 2013 19:39:38 -0500 Received: by mail-qa0-f45.google.com with SMTP id g10so2024296qah.4 for <13578@debbugs.gnu.org>; Mon, 25 Feb 2013 16:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=7JV7ZK7KKaJxX4NJ0JudFTs6kUr25vFU4U9Nj/IBKb0=; b=maQLjaOIHQGtFXAn8BRf+ou0mZk3TZjwLsGtntSnowjvUEJ9gIb2zeDFHxfCLD8NtO VqlE7ALGu6YyhH8LobPQ634fjIEgjXht0KWYPO5fkHAiyWmTeoh8cA+i+Xv4y5q8NeY/ 0/xTA+Vuh4KY8iKGERvVlye5p9FqZNp7OPeOp4IXp1F3F6w+ahZd/6SXnXsjjHJRIAgd sTtt4VyVaS8b9rarp6sCruMqWqW/GKz9Gt350/4a6079ArqfobbVbqsiFmqBcSrj8BQc qErr8VQUPlWkLYbJwvjwZChCwU17JNK7HXHFgWcZa2GTTtRYAnVeftjiNGT6id2geHG3 nD5g== X-Received: by 10.49.5.7 with SMTP id o7mr4528172qeo.30.1361839075338; Mon, 25 Feb 2013 16:37:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.83 with HTTP; Mon, 25 Feb 2013 16:37:15 -0800 (PST) In-Reply-To: <512BEEAA.4010106@gmail.com> References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B69D5.9070308@gmail.com> <87wqtwkoyq.fsf@catnip.gol.com> <512BEEAA.4010106@gmail.com> From: Miles Bader Date: Tue, 26 Feb 2013 09:37:15 +0900 X-Google-Sender-Auth: 8hKFDd2WM84lkoHSHGbU1sWW-to Message-ID: Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) Just that by far the most common branch setup in git repos seems to be using master as the "dev trunk", with releases, release candidates (etc) on special branches. There are often additional feature branches for even more speculative changes, but master is generally not really "safe," even if it's not the most dangerous branch. So master tends to be a sort of "middle" state (between release/release-candidate branches and speculative feature branches), stuff that is slated for the next release, and has received review -- but may still have some bugs to be shaken out. For complicated long-term changes, people often do development on special feature branches, but smaller and more straight-forward changes generally get put into master directly. Master branches break with some regularity. If you're familiar with gcc's subversion repo setup, it's pretty similar to this (with the subversion trunk being "master") Git's own repo actually does this too. Thanks, -miles -- Cat is power. Cat is peace. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 26 Feb 2013 18:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Peter Rosin Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13619035389847 (code B ref 13578); Tue, 26 Feb 2013 18:33:01 +0000 Received: (at 13578) by debbugs.gnu.org; 26 Feb 2013 18:32:18 +0000 Received: from localhost ([127.0.0.1]:51581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAPK5-0002Yl-Uf for submit@debbugs.gnu.org; Tue, 26 Feb 2013 13:32:18 -0500 Received: from mail-ee0-f51.google.com ([74.125.83.51]:37244) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAPK1-0002Yb-Pd for 13578@debbugs.gnu.org; Tue, 26 Feb 2013 13:32:16 -0500 Received: by mail-ee0-f51.google.com with SMTP id d17so2581131eek.24 for <13578@debbugs.gnu.org>; Tue, 26 Feb 2013 10:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A5G0geBgabiyQ9kqH4ltiTxb3cHk3rV7eK2pEYB7h9c=; b=Eqyhp1UW2HVCpVPBhnOdxnKMloMa2shsKdjLwg8VBgXINgJ3lu8Ho3RW3VuX+nH524 eLd7NnndRK6l7nRxS2qTS9Kl5SnaDONWBkQVB09mJdi4qgMjAE/MvPKTVHPEM03h0cuM N75s4bbflWaza11V3RqhE8vcTS5kDo1CVfEJ6xnQQyt9Gdc5al5vwcHyWpiYvArVu1pg EV6VS4zV+HZGSLYUV8sDwMRHtGsCmEcKkYV/Jb7xRPcMXWQkL0aN92+VMnxl+xMD6xKj P6SXQaRZiBmz2N5tjYmApeYIA79Ey4wsPi2+rDb34xrwcvmJshTBl8Ej7RqyaWDtaU+f hvxA== X-Received: by 10.14.216.198 with SMTP id g46mr52020620eep.30.1361903426919; Tue, 26 Feb 2013 10:30:26 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id a1sm2793242eep.2.2013.02.26.10.30.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 10:30:25 -0800 (PST) Message-ID: <512CFF36.4010506@gmail.com> Date: Tue, 26 Feb 2013 19:30:14 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> In-Reply-To: <512BF967.1040701@lysator.liu.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Peter. On 02/26/2013 12:53 AM, Peter Rosin wrote: > On 2013-02-25 10:16, Stefano Lattarini wrote: > >> >> Note that the users can avoid branch-rewriting issues by renaming their >> 'master' to 'next' and their 'maint' to 'master' before pulling. This >> should probably be stated in a message (on list *and* on savannah news) >> advertising the new versioning and branching scheme (message not yet >> written; it will be once the current issue is sorted out). > > Hiding stuff like that in some documentation or on a mailing list will > not help. You should make it *easy* for people to work on and contribute > to automake. Forcing everyone to do a bunch of silly boring renames > is not *easy*. It's an obstacle, and obstacles make people nervous > and uneasy. Not good, and no, you can't document it away. > You might have good points, and possibly even be completely right... But I must ask, why didn't you step up during the lengthy discussion about this change, nor objected during the delay (almost a week) that was deliberately let pass between the decision and the implementation -- precisely to let this kind of late objections to come out? What is the point of having such discussions in the first place, if people who oppose a proposed change (maybe even on solid ground and with sound reasons) only object *after* the change has been discussed, accepted and implemented? >>> It's quite hostile to do non-fast-forwards >>> on branches as central as master and maint. And I think git/savannah >>> is rejecting them quite rightly! >>> >> Savannah is rejecting all non-fast-forward pushes (which I find annoying); >> but it didn't prevent me from deleting and recreating maint, a change that >> will still appear as a non-fast-forward to any clone of our repository. >> >> The reason it doesn't allow me to delete master as well is that doing so >> would prevent a "git clone" from checking out the sources of a freshly >> cloned automake, which can be very confusing (and of course, git cannot >> be aware of the fact that I intend to re-create 'master' just after >> having deleted it). > > The reason is irrelevant. non-fast-forwards of central branches is evil. > Mostly, yes. This time, considering that no commits were actually being dropped or rewritten, I believed it wasn't not that bad, and was IMHO justified by the new improved versioning and branching scheme. And while you *might* have changed my mind before (because you have valid points, and maybe it would have better to err on the side of safety), I have now already rewritten maint, so rather than messing up by rewriting it again (to its old value, granted, but a rewrite nonetheless) and reverting an already made decision (and made after considerable discussion and not negligible efforts), I'd rather stuck with the current minor "mess". That said, if it turns out that I'm in minority in supporting such an approach, then feel free to revert the maint rewrite [1] (and I'll drop the planned master rewrite); I'm not here to forcibly impose my will on the majority, at least not when the majority has good points or valid concerns. [1] And rename the bug-fixing branch to something like 'fix' or 'micro', and adjust HACKING accordingly -- with a clear and explicative commit message. Whatever the result will be, I'm starting to lose faith in the usefulness of having lengthy discussion for controversial changes beforehand; if we don't and I just go ahead with my idea, some (or most) people will complain after the fact; if we do, and a consensus is reached and implemented, some people still complain after the fact. Not a great situation, motivational-wise ... >>> master and maint have never been published as "rewindable", and it should >>> be correct to base new work on them. They should be left alone, IMHO. >>> >> Their content has been left alone in fact; it's their "name" that hasn't. >> >>> You should have implemented this more gradually, such that next would >>> have taken its role directly, but maint and master should have been >>> allowed to grow into the correct branches once the relevant releases had >>> been made. >>> >> This would give a very confusing interim period IMHO. > > Yes, confusing. Changes like this cause confusion. > >> However, note that that we can still implement such a "gentler transition" >> (for 'master' only) if you really want to, by using a new branch name >> (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a >> temporary "alias" to 'next' until the 2.0 release (at which point all of >> 'maint', 'master' and 'next' will be fast-forwarded to the commit that >> implements the 2.0 release). I still prefer to pull this sore tooth out >> right now, though. > > So messy. > Indeed. Better be consistent and rewrite 'master' too. >>> Or even better, implement the change right after a major >>> release so that master and maint would have been correctly positioned >>> from the start. >>> >>> I have a few single-commit local branches that I will simply have to >>> cherry-pick to the new world order. >>> >> No, just rebase them on the new name of the branch they were based on; >> that is, if they were based on 'master', they are now to be considered >> based on 'next', if they were based on 'maint', they are now to be >> considered based on 'master', and if they were based on 'branch-1.13.2' >> they are not to be considered based on 'maint'. > > ( s/are not to/are now to/ ) > Yes, sorry for the typo. > Yes, that works. But it is a nuisance. > Yes, but an easily bearable one IMHO. >>> Or is there some better way to move >>> these branches after their base has been pulled from under them? >>> >> The good thing is that is has not been really pulled away, just *renamed*. >> >> Remember that Git branches are just "movable tags" basically, so as long >> as you have another "handle" referencing the same commit a branch points >> to (be that a tag or another branch), nothing is lost by removing the >> branch -- you are just removing a tag, not any "real" content. > > Yes, but the "renames" are extremely surprising to a casual contributor. > > What if someone has a few commits on, say maint, from before your rename. > This someone didn't bother to create a topic branch for these commits > for some reason. What happens when those local commits have been forgotten > and the new-world-order is pulled? A merge is attempted of the local commits > and the whole difference between old and new maint. That is likely to > result in a conflict. So, our imaginary dev restores the local maint and > puts the local commits on a topic branch and retries only to again see > a conflict when the pull is attempted. I bet the poor dev will not first > think that upstream has messed up, but that it is some local crap that is > happening. How much time will be wasted? > > BTW, just to test this I did the perfectly valid (no local commits on > maint): > > git checkout maint > git pull > > And my repo is now in a mess with unresolved conflicts. This rename > is a mess. It is only clean for you, since it originated from you. > Everyone else will have to take about the same manual steps you > did in order to follow. Which is crappy and evil and will only work > for those of us who pay close attention to the mailing list/docs. > The poor sods with a git checkout as of last week but having no reason > to pull for some time will wonder what hit them when they actually do > pull. > OK, I thought about those considerations, but the situation seemed much less bleak and by no means catastrophic to me; maybe you are right that that was only due to the fact that the change originated from myself, so I was fully aware of what it would entail, and didn't try too hard to put myself in the shoes of casual contributors, who weren't privy to such details. Then again (pardon me for being whiny) why didn't you object in time? Sigh ... > Also, git history is fuubared. > No, having it fubared would mean that at least some once valid SHA-1 have become invalid; this haven't happen. > E.g. commit 0756a43c3a77 > "Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint. > How confusing is that? > >>> Hopefully there isn't some big chunk of unpublished work that will be >>> killed by these disruptive changes... >>> >> No, there is not. As said, no pre-existing commit has been dropped by >> my planned renames. > > Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 01:27:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Peter Rosin , 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136192841614492 (code B ref 13578); Wed, 27 Feb 2013 01:27:03 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 01:26:56 +0000 Received: from localhost ([127.0.0.1]:51990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAVnM-0003lh-2P for submit@debbugs.gnu.org; Tue, 26 Feb 2013 20:26:56 -0500 Received: from smtp11.dentaku.gol.com ([203.216.5.73]:50512) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAVnI-0003lX-7d for 13578@debbugs.gnu.org; Tue, 26 Feb 2013 20:26:53 -0500 Received: from 218.33.195.56.eo.eaccess.ne.jp ([218.33.195.56] helo=catnip.gol.com) by smtp11.dentaku.gol.com with esmtpa (Dentaku) (envelope-from ) id 1UAVlV-0002TX-Pi; Wed, 27 Feb 2013 10:25:01 +0900 Received: by catnip.gol.com (Postfix, from userid 1000) id C71EFDFC1; Wed, 27 Feb 2013 10:25:00 +0900 (JST) From: Miles Bader References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> System-Type: x86_64-unknown-linux-gnu Date: Wed, 27 Feb 2013 10:25:00 +0900 In-Reply-To: <512CFF36.4010506@gmail.com> (Stefano Lattarini's message of "Tue, 26 Feb 2013 19:30:14 +0100") Message-ID: <87a9qqlf9v.fsf@catnip.gol.com> Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) Stefano Lattarini writes: > You might have good points, and possibly even be completely right... > But I must ask, why didn't you step up during the lengthy discussion > about this change, nor objected during the delay (almost a week) that > was deliberately let pass between the decision and the implementation > -- precisely to let this kind of late objections to come out? I just didn't notice the name change... >< -miles -- Egotist, n. A person of low taste, more interested in himself than in me. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 01:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Peter Rosin , 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136192879015168 (code B ref 13578); Wed, 27 Feb 2013 01:34:02 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 01:33:10 +0000 Received: from localhost ([127.0.0.1]:52011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAVtO-0003wb-1E for submit@debbugs.gnu.org; Tue, 26 Feb 2013 20:33:10 -0500 Received: from smtp11.dentaku.gol.com ([203.216.5.73]:40521) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAVtL-0003wU-WF for 13578@debbugs.gnu.org; Tue, 26 Feb 2013 20:33:08 -0500 Received: from 218.33.195.56.eo.eaccess.ne.jp ([218.33.195.56] helo=catnip.gol.com) by smtp11.dentaku.gol.com with esmtpa (Dentaku) (envelope-from ) id 1UAVra-0002ve-Mm; Wed, 27 Feb 2013 10:31:18 +0900 Received: by catnip.gol.com (Postfix, from userid 1000) id 03818DFC1; Wed, 27 Feb 2013 10:31:17 +0900 (JST) From: Miles Bader References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> System-Type: x86_64-unknown-linux-gnu Date: Wed, 27 Feb 2013 10:31:17 +0900 In-Reply-To: <512CFF36.4010506@gmail.com> (Stefano Lattarini's message of "Tue, 26 Feb 2013 19:30:14 +0100") Message-ID: <874ngyleze.fsf@catnip.gol.com> Lines: 24 MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) Stefano Lattarini writes: > And while you *might* have changed my mind before (because you have > valid points, and maybe it would have better to err on the side of > safety), I have now already rewritten maint, so rather than messing > up by rewriting it again (to its old value, granted, but a rewrite > nonetheless) and reverting an already made decision (and made after > considerable discussion and not negligible efforts), I'd rather > stuck with the current minor "mess". Rewriting "to the old value" makes a _huge_ difference (at least with git), because people that haven't done a pull or whatever of the "new value" will then have no problem at all. So whether another rename causes more or less pain depends on what proportion of people that have a pointer to your repository do frequent updates. As automake seems to be the sort of project that has mostly "casual" contributors, I'd wager many people _haven't_ pulled the "changed" version, and so would be _helped_ by a rename-to-the-old-value (and hurt by not doing so). -miles -- Arrest, v. Formally to detain one accused of unusualness. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 09:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Miles Bader Cc: Peter Rosin , 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136195637323949 (code B ref 13578); Wed, 27 Feb 2013 09:13:02 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 09:12:53 +0000 Received: from localhost ([127.0.0.1]:52528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAd4H-0006EE-66 for submit@debbugs.gnu.org; Wed, 27 Feb 2013 04:12:53 -0500 Received: from mail-ee0-f52.google.com ([74.125.83.52]:39401) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAd4E-0006E4-Q8 for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 04:12:51 -0500 Received: by mail-ee0-f52.google.com with SMTP id b15so227386eek.25 for <13578@debbugs.gnu.org>; Wed, 27 Feb 2013 01:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=p2bebqMRDSZ8SwPPlJJjr8y+8F9V9rwOiJcuSV4Syos=; b=KqgrvwxEB+iFZkZoLLCEEneZCMpKrGcBfvBQEW6a3irLlOhUQF5j85VfYHwIgk3EuY 9cwmXUr6dz4FHQ0/siYJ5cba3EVB6rtm1GjQak6wfqym4V+RMqUy8OuXyD3pJiWxRtQv E2WB8OIMQsVr6HXzBE+NUSVqsJpAisgBWVYN5y7rcbeGdUrzs/ZSu1X3jKAY6wn7IxkQ eOotli8R73DrDlsNZpj++ZHHt9Jt/ZmEoNs2Ec5mK5KxE7PYl7z+j5lRHgcM2/UzlZk3 L1P+kHC+8Nf8dn/1hIXMWsalr4AsQ2XhHSC//Ja8j08dMkNoVcPkp4u2ftemplQHyEYF BuxA== X-Received: by 10.14.210.8 with SMTP id t8mr4289618eeo.35.1361956260367; Wed, 27 Feb 2013 01:11:00 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id f47sm5268948eep.13.2013.02.27.01.10.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 01:10:59 -0800 (PST) Message-ID: <512DCD9B.7080300@gmail.com> Date: Wed, 27 Feb 2013 10:10:51 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <87a9qqlf9v.fsf@catnip.gol.com> In-Reply-To: <87a9qqlf9v.fsf@catnip.gol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/27/2013 02:25 AM, Miles Bader wrote: > Stefano Lattarini writes: >> You might have good points, and possibly even be completely right... >> But I must ask, why didn't you step up during the lengthy discussion >> about this change, nor objected during the delay (almost a week) that >> was deliberately let pass between the decision and the implementation >> -- precisely to let this kind of late objections to come out? > > I just didn't notice the name change... >< > In retrospective, since that change wasn't strictly required to implement the new versioning scheme, it should have been proposed and discussed in a separate thread, to make sure it sticked out properly ... Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 09:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Miles Bader Cc: Peter Rosin , 13578@debbugs.gnu.org, Automake List Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136195649124144 (code B ref 13578); Wed, 27 Feb 2013 09:15:01 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 09:14:51 +0000 Received: from localhost ([127.0.0.1]:52536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAd6A-0006HN-Q7 for submit@debbugs.gnu.org; Wed, 27 Feb 2013 04:14:51 -0500 Received: from mail-ee0-f47.google.com ([74.125.83.47]:43866) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAd69-0006HG-3y for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 04:14:49 -0500 Received: by mail-ee0-f47.google.com with SMTP id e52so240220eek.34 for <13578@debbugs.gnu.org>; Wed, 27 Feb 2013 01:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SjauLYUYgI00JTx4gaoHqO5a7Tse0AjMivgOrX+T/80=; b=tgSqNcHDNIOV+0Als1kyiIpghg3zXBsjfq/QYnRDDO5ZXKKLxVZA+BTeNZqAioA5ns KAI5MChNG6oosbKz34DuF1vzhKHBDly0bpcQnjos5ND1gVpTz8N3P2uIFkNXsZ/BEMpi oJXX11YWZwJ67ulq9ditw+TpFR4wzs22poeQ1QNkYRHCRIEZSeKNfMi15prFk5k4IqUw TAs2zLbNP4BRGfRFBmq2CVCWWPDexqYRb8GalwRkK9AiIRMCDPoMP+WY/VRt/ZYqXL/W gDXxvS7aTu299HjB16+b457AEXJp/9gpZkuTa5RIgrCF+90GSc0Srsoq+T3vmW+JgPR7 rnvA== X-Received: by 10.14.0.73 with SMTP id 49mr4393181eea.21.1361956379015; Wed, 27 Feb 2013 01:12:59 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id q42sm5276990eem.14.2013.02.27.01.12.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 01:12:58 -0800 (PST) Message-ID: <512DCE18.5090107@gmail.com> Date: Wed, 27 Feb 2013 10:12:56 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <874ngyleze.fsf@catnip.gol.com> In-Reply-To: <874ngyleze.fsf@catnip.gol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/27/2013 02:31 AM, Miles Bader wrote: > Stefano Lattarini writes: >> And while you *might* have changed my mind before (because you have >> valid points, and maybe it would have better to err on the side of >> safety), I have now already rewritten maint, so rather than messing >> up by rewriting it again (to its old value, granted, but a rewrite >> nonetheless) and reverting an already made decision (and made after >> considerable discussion and not negligible efforts), I'd rather >> stuck with the current minor "mess". > > Rewriting "to the old value" makes a _huge_ difference (at least with > git), because people that haven't done a pull or whatever of the "new > value" will then have no problem at all. > > So whether another rename causes more or less pain depends on what > proportion of people that have a pointer to your repository do > frequent updates. As automake seems to be the sort of project that > has mostly "casual" contributors, I'd wager many people _haven't_ > pulled the "changed" version, and so would be _helped_ by a > rename-to-the-old-value (and hurt by not doing so). > As I said in my reply to Peter, feel free to reach a decision on-list and implement it. I'm not going to touch the Automake repository myself for some (possibly several) days anyway. Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Peter Rosin Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 09:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136195745325582 (code B ref 13578); Wed, 27 Feb 2013 09:31:01 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 09:30:53 +0000 Received: from localhost ([127.0.0.1]:52568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAdLg-0006eY-99 for submit@debbugs.gnu.org; Wed, 27 Feb 2013 04:30:53 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]:47267) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAdLc-0006eP-Nk for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 04:30:51 -0500 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id DACB640006; Wed, 27 Feb 2013 10:28:57 +0100 (CET) Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com [90.227.119.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 7363740002; Wed, 27 Feb 2013 10:28:57 +0100 (CET) Message-ID: <512DD1D8.20303@lysator.liu.se> Date: Wed, 27 Feb 2013 10:28:56 +0100 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> In-Reply-To: <512CFF36.4010506@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 2013-02-26 19:30, Stefano Lattarini wrote: > Hi Peter. > > On 02/26/2013 12:53 AM, Peter Rosin wrote: >> On 2013-02-25 10:16, Stefano Lattarini wrote: >> >>> >>> Note that the users can avoid branch-rewriting issues by renaming their >>> 'master' to 'next' and their 'maint' to 'master' before pulling. This >>> should probably be stated in a message (on list *and* on savannah news) >>> advertising the new versioning and branching scheme (message not yet >>> written; it will be once the current issue is sorted out). >> >> Hiding stuff like that in some documentation or on a mailing list will >> not help. You should make it *easy* for people to work on and contribute >> to automake. Forcing everyone to do a bunch of silly boring renames >> is not *easy*. It's an obstacle, and obstacles make people nervous >> and uneasy. Not good, and no, you can't document it away. >> > You might have good points, and possibly even be completely right... > But I must ask, why didn't you step up during the lengthy discussion > about this change, nor objected during the delay (almost a week) that > was deliberately let pass between the decision and the implementation > -- precisely to let this kind of late objections to come out? What is > the point of having such discussions in the first place, if people who > oppose a proposed change (maybe even on solid ground and with sound > reasons) only object *after* the change has been discussed, accepted > and implemented? The long winding "eyes glossing over" discussion about version numbers had nothing in it about branches, except the initial proposal which stated: * None of 'maint', 'master' and 'next' should be rewindable. I was not aware that 'master' and 'next' were rewindable before. Then there was the last message before the implementation that stated: In a couple of days, I will proceed with this "branch moving": * branch-1.13.2 -> maint * maint -> master * master -> next No other message mentions git branches that I could find, but I might have missed some instance. Now, there are more than one way to "move branches". The most natural is to merge your way forward, in fact that's the only one that makes sense if the branches are *not* *rewindable*. Thinking about this for a few minutes, I think I would have (with better commit messages): # create 'next' $ git branch next master # update 'master' $ git branch new-master maint $ git checkout new-master $ git merge --strategy=ours master -m "rename maint -> master" $ git checkout master $ git merge new-master # a simple fast-forward $ git branch -D new-master # update 'maint' $ git branch new-maint branch-1.13.2 $ git checkout new-maint $ git merge --strategy=ours maint -m "rename branch-1.13.2 -> maint" $ git checkout maint $ git merge new-maint # a simple fast-forward $ git branch -D new-maint Forgive me for assuming that the branches would not be rewound. Also, I was away skiing last week, but I wouldn't have caught this even if I had been "present". BTW, I assume you could still use the mid part to update master, instead of waiting for the savannah crew to help you. You just have to replace the first "git branch new-master ..." with $ git branch new-master b4dbcb75 (Because I think b4dbcb75 is what 'maint' was before you rewrote it.) >>>> It's quite hostile to do non-fast-forwards >>>> on branches as central as master and maint. And I think git/savannah >>>> is rejecting them quite rightly! >>>> >>> Savannah is rejecting all non-fast-forward pushes (which I find annoying); >>> but it didn't prevent me from deleting and recreating maint, a change that >>> will still appear as a non-fast-forward to any clone of our repository. >>> >>> The reason it doesn't allow me to delete master as well is that doing so >>> would prevent a "git clone" from checking out the sources of a freshly >>> cloned automake, which can be very confusing (and of course, git cannot >>> be aware of the fact that I intend to re-create 'master' just after >>> having deleted it). >> >> The reason is irrelevant. non-fast-forwards of central branches is evil. >> > Mostly, yes. This time, considering that no commits were actually being > dropped or rewritten, I believed it wasn't not that bad, and was IMHO > justified by the new improved versioning and branching scheme. > > And while you *might* have changed my mind before (because you have > valid points, and maybe it would have better to err on the side of > safety), I have now already rewritten maint, so rather than messing > up by rewriting it again (to its old value, granted, but a rewrite > nonetheless) and reverting an already made decision (and made after > considerable discussion and not negligible efforts), I'd rather stuck > with the current minor "mess". > > That said, if it turns out that I'm in minority in supporting such an > approach, then feel free to revert the maint rewrite [1] (and I'll drop > the planned master rewrite); I'm not here to forcibly impose my will > on the majority, at least not when the majority has good points or > valid concerns. > > [1] And rename the bug-fixing branch to something like 'fix' > or 'micro', and adjust HACKING accordingly -- with a clear > and explicative commit message. > > Whatever the result will be, I'm starting to lose faith in the > usefulness of having lengthy discussion for controversial changes > beforehand; if we don't and I just go ahead with my idea, some (or > most) people will complain after the fact; if we do, and a consensus > is reached and implemented, some people still complain after the > fact. Not a great situation, motivational-wise ... The branch rewinding was not discussed at all, I don't think anyone even realized it was on the map. Personally, I couldn't care less if the next major is called 1.14 or 2.0, so I felt I had nothing to add to the discussion. >>>> master and maint have never been published as "rewindable", and it should >>>> be correct to base new work on them. They should be left alone, IMHO. >>>> >>> Their content has been left alone in fact; it's their "name" that hasn't. >>> >>>> You should have implemented this more gradually, such that next would >>>> have taken its role directly, but maint and master should have been >>>> allowed to grow into the correct branches once the relevant releases had >>>> been made. >>>> >>> This would give a very confusing interim period IMHO. >> >> Yes, confusing. Changes like this cause confusion. >> >>> However, note that that we can still implement such a "gentler transition" >>> (for 'master' only) if you really want to, by using a new branch name >>> (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a >>> temporary "alias" to 'next' until the 2.0 release (at which point all of >>> 'maint', 'master' and 'next' will be fast-forwarded to the commit that >>> implements the 2.0 release). I still prefer to pull this sore tooth out >>> right now, though. >> >> So messy. >> > Indeed. Better be consistent and rewrite 'master' too. > >>>> Or even better, implement the change right after a major >>>> release so that master and maint would have been correctly positioned >>>> from the start. >>>> >>>> I have a few single-commit local branches that I will simply have to >>>> cherry-pick to the new world order. >>>> >>> No, just rebase them on the new name of the branch they were based on; >>> that is, if they were based on 'master', they are now to be considered >>> based on 'next', if they were based on 'maint', they are now to be >>> considered based on 'master', and if they were based on 'branch-1.13.2' >>> they are not to be considered based on 'maint'. >> >> ( s/are not to/are now to/ ) >> > Yes, sorry for the typo. > >> Yes, that works. But it is a nuisance. >> > Yes, but an easily bearable one IMHO. Obviously. You have already updated to the new world order, so of course it's easy for you to bear it. It's relatively easy for anyone that's aware of the branch rewrite, but you simply can't get the message out to all parties. Also, at no point have you described how a git newbie should adjust the local repo, that git fetch is needed because git pull simply will not work etc. >>>> Or is there some better way to move >>>> these branches after their base has been pulled from under them? >>>> >>> The good thing is that is has not been really pulled away, just *renamed*. >>> >>> Remember that Git branches are just "movable tags" basically, so as long >>> as you have another "handle" referencing the same commit a branch points >>> to (be that a tag or another branch), nothing is lost by removing the >>> branch -- you are just removing a tag, not any "real" content. >> >> Yes, but the "renames" are extremely surprising to a casual contributor. >> >> What if someone has a few commits on, say maint, from before your rename. >> This someone didn't bother to create a topic branch for these commits >> for some reason. What happens when those local commits have been forgotten >> and the new-world-order is pulled? A merge is attempted of the local commits >> and the whole difference between old and new maint. That is likely to >> result in a conflict. So, our imaginary dev restores the local maint and >> puts the local commits on a topic branch and retries only to again see >> a conflict when the pull is attempted. I bet the poor dev will not first >> think that upstream has messed up, but that it is some local crap that is >> happening. How much time will be wasted? >> >> BTW, just to test this I did the perfectly valid (no local commits on >> maint): >> >> git checkout maint >> git pull >> >> And my repo is now in a mess with unresolved conflicts. This rename >> is a mess. It is only clean for you, since it originated from you. >> Everyone else will have to take about the same manual steps you >> did in order to follow. Which is crappy and evil and will only work >> for those of us who pay close attention to the mailing list/docs. >> The poor sods with a git checkout as of last week but having no reason >> to pull for some time will wonder what hit them when they actually do >> pull. >> > OK, I thought about those considerations, but the situation seemed much Why why why didn't you explain that in your rationale when proposing the change? If you truly wanted input, you should have stated the negatives as well in case someone had stronger reasons for being negative. > less bleak and by no means catastrophic to me; maybe you are right that > that was only due to the fact that the change originated from myself, so > I was fully aware of what it would entail, and didn't try too hard to put > myself in the shoes of casual contributors, who weren't privy to such > details. > > Then again (pardon me for being whiny) why didn't you object in time? > Sigh ... As stated in my original complaint: "I was not aware that those moves would be non-fast-forwards, and I think ..." >> Also, git history is fuubared. >> > No, having it fubared would mean that at least some once valid SHA-1 > have become invalid; this haven't happen. Oh, that's perhaps what it means to have the history fubared according to your definition, but I stated that it was fuubared (with two 'u's, mind you), which is something completely different according to my definition. When this change has been forgotten (and it will be), it will no longer be possible to say what 'maint' was as of 2013-01-15 by only looking at the git history. You would have to know that a branch rewrite took place. Ergo, the history has been fuubared. >> E.g. commit 0756a43c3a77 >> "Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint. >> How confusing is that? >> >>>> Hopefully there isn't some big chunk of unpublished work that will be >>>> killed by these disruptive changes... >>>> >>> No, there is not. As said, no pre-existing commit has been dropped by >>> my planned renames. Cheers, Peter From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Peter Rosin Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 09:40:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136195795926459 (code B ref 13578); Wed, 27 Feb 2013 09:40:03 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 09:39:19 +0000 Received: from localhost ([127.0.0.1]:52606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAdTo-0006se-B5 for submit@debbugs.gnu.org; Wed, 27 Feb 2013 04:39:18 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]:57038) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAdTk-0006sT-VZ for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 04:39:13 -0500 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CB34E4000B; Wed, 27 Feb 2013 10:37:22 +0100 (CET) Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com [90.227.119.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 710BA40002; Wed, 27 Feb 2013 10:37:22 +0100 (CET) Message-ID: <512DD3D1.4010800@lysator.liu.se> Date: Wed, 27 Feb 2013 10:37:21 +0100 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> In-Reply-To: <512DD1D8.20303@lysator.liu.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 2013-02-27 10:28, Peter Rosin wrote: > The long winding "eyes glossing over" discussion about version numbers > had nothing in it about branches, except the initial proposal which > stated: > > * None of 'maint', 'master' and 'next' should be rewindable. > > I was not aware that 'master' and 'next' were rewindable before. I meant 'maint', not 'next', in the last sentence. Of course. Cheers, Peter From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 10:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Peter Rosin Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136196110731047 (code B ref 13578); Wed, 27 Feb 2013 10:32:02 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 10:31:47 +0000 Received: from localhost ([127.0.0.1]:52654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAeIc-00084h-93 for submit@debbugs.gnu.org; Wed, 27 Feb 2013 05:31:46 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:34263) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAeIa-00084a-91 for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 05:31:45 -0500 Received: by mail-ee0-f46.google.com with SMTP id e49so310629eek.19 for <13578@debbugs.gnu.org>; Wed, 27 Feb 2013 02:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jxvZNHYO0xXcmZPJjxi0M7BHNRxrUWphBYg7WZLlbAk=; b=tXhiU9i/eN14zSuruygeF/Hgx+gSZHuE/y6zQ6E/JtR/2nX5wI6fmOeF065W2/2MsI p+lAtFCWCPhWGay9N14DmJFBh6qyOg5o7xLlnQkbVmFMR1cMkSHST4O8IW+ZicoJm5hx hH8LBS1wC5XvZfXFlL2q5fv4Kp8UXcW4BE0dhqe9bRPWF/KbiZuOtg2SmOgN4gDB2ksF d3ypvsydYf/iyAexeI6O30ahLDDMg3AO/L+2XA89V3CgnzsXK4zIZPJiGkzHiN1gIDro 9sqCppPj6kYCE+aXXPQ/z0tzita9yilctAsRHha+gY1Yi44XKcCe9uRzaiIeEWtYwTwF 69+A== X-Received: by 10.14.179.5 with SMTP id g5mr4896168eem.41.1361960993700; Wed, 27 Feb 2013 02:29:53 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id q42sm5628855eem.14.2013.02.27.02.29.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 02:29:52 -0800 (PST) Message-ID: <512DE017.50505@gmail.com> Date: Wed, 27 Feb 2013 11:29:43 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> In-Reply-To: <512DD1D8.20303@lysator.liu.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/27/2013 10:28 AM, Peter Rosin wrote: > > [SNIP] > > The long winding "eyes glossing over" discussion about version numbers > had nothing in it about branches, except the initial proposal which > stated: > > * None of 'maint', 'master' and 'next' should be rewindable. > It also stated: I also propose the following change to the branching scheme currently implemented in the Automake Git repository: * The 'maint' branch will be reserved to cut of the next micro release; so it will just see fixes for regressions, trivial bugs, or documentation issues, and no "active" development whatsoever. * The 'master' branch will be where the development of the next minor release will take place; that is, a sort of "middle-ground" between the roles so far fulfilled by the 'maint' and 'master' branches in the current branching scheme. * The (new) 'next' branch will be reserved for the development of the next major release; it will basically take over the rule that is currently fulfilled by the 'master' branch. I thought that was making clear that the then-current 'maint' and 'master' branches would have needed to be renamed in order to implement that new scheme. But re-reading the above, I realize I wasn't making that clear at all (it sounded clear to me because the details were fresh and clear in my mind then). > I was not aware that 'master' and 'next' were rewindable before. > > Then there was the last message before the implementation that stated: > > In a couple of days, I will proceed with this "branch moving": > > * branch-1.13.2 -> maint > * maint -> master > * master -> next > > > No other message mentions git branches that I could find, but I might > have missed some instance. > > Now, there are more than one way to "move branches". The most natural > is to merge your way forward, > Not in this case, as 'master' had several commits lacking in 'maint'. > in fact that's the only one that makes > sense if the branches are *not* *rewindable*. > > Thinking about this for a few minutes, I think I would have (with > better commit messages): > # create 'next' > $ git branch next master > > # update 'master' > $ git branch new-master maint > $ git checkout new-master > $ git merge --strategy=ours master -m "rename maint -> master" > This would have obtained the wrong effect; what was in master before my attempted renaming shouldn't have landed in the new 'master', but only in 'next'. In the new 'master', we only wanted what was in the old 'maint'. > $ git checkout master > $ git merge new-master # a simple fast-forward > $ git branch -D new-master > > # update 'maint' > $ git branch new-maint branch-1.13.2 > $ git checkout new-maint > $ git merge --strategy=ours maint -m "rename branch-1.13.2 -> maint" > $ git checkout maint > $ git merge new-maint # a simple fast-forward > $ git branch -D new-maint > Same issue as above. > Forgive me for assuming that the branches would not be rewound. > > Also, I was away skiing last week, but I wouldn't have caught this > even if I had been "present". > > BTW, I assume you could still use the mid part to update master, instead > of waiting for the savannah crew to help you. > Of course, we don't need any help from Savannah, since, as I said, no commit has been lost. If you want to revert the botched renaming, you just need to rename the current 'maint' to 'branch-1.13.2', and recover the previous 'maint' from the last merge into 'master' (that has not been re-written), and delete the 'next' branch. As I said, if you reach a consensus on that (and I guess you will), feel free to go ahead with that. No objection from me. > You just have to replace > the first "git branch new-master ..." with > > $ git branch new-master b4dbcb75 > > (Because I think b4dbcb75 is what 'maint' was before you rewrote it.) >> >> [BIG SNIP] >> >> OK, I thought about those considerations, but the situation seemed much >> less bleak [SNIP] > > Why why why didn't you explain that in your rationale when proposing > the change? If you truly wanted input, you should have stated the > negatives as well in case someone had stronger reasons for being > negative. > Because I mistakenly didn't think they were relevant negatives. So new rule for me: from now on, all the negative sides I can think of are relevant, no matter how tiny or even "irrelevant" they appear to me. > [SNIP] Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Peter Rosin Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 23:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13620061264956 (code B ref 13578); Wed, 27 Feb 2013 23:03:02 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 23:02:06 +0000 Received: from localhost ([127.0.0.1]:54315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAq0i-0001Hs-SW for submit@debbugs.gnu.org; Wed, 27 Feb 2013 18:02:05 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]:37778) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAq0e-0001HS-ID for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 18:02:03 -0500 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3AC6540008; Thu, 28 Feb 2013 00:00:06 +0100 (CET) Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com [90.227.119.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id BC26340005; Thu, 28 Feb 2013 00:00:05 +0100 (CET) Message-ID: <512E8FF4.1090102@lysator.liu.se> Date: Thu, 28 Feb 2013 00:00:04 +0100 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> In-Reply-To: <512DE017.50505@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 2013-02-27 11:29, Stefano Lattarini wrote: > On 02/27/2013 10:28 AM, Peter Rosin wrote: >> >> [SNIP] >> >> The long winding "eyes glossing over" discussion about version numbers >> had nothing in it about branches, except the initial proposal which >> stated: >> >> * None of 'maint', 'master' and 'next' should be rewindable. >> > It also stated: > > I also propose the following change to the branching scheme currently > implemented in the Automake Git repository: > > * The 'maint' branch will be reserved to cut of the next micro > release; so it will just see fixes for regressions, trivial > bugs, or documentation issues, and no "active" development > whatsoever. > > * The 'master' branch will be where the development of the next > minor release will take place; that is, a sort of "middle-ground" > between the roles so far fulfilled by the 'maint' and 'master' > branches in the current branching scheme. > > * The (new) 'next' branch will be reserved for the development > of the next major release; it will basically take over the rule > that is currently fulfilled by the 'master' branch. > > I thought that was making clear that the then-current 'maint' and > 'master' branches would have needed to be renamed in order to implement > that new scheme. But re-reading the above, I realize I wasn't making > that clear at all (it sounded clear to me because the details were > fresh and clear in my mind then). It also didn't state *when* the roles would change. The natural point is after a major release when master and maint have converged anyway. >> I was not aware that 'master' and 'next' were rewindable before. >> >> Then there was the last message before the implementation that stated: >> >> In a couple of days, I will proceed with this "branch moving": >> >> * branch-1.13.2 -> maint >> * maint -> master >> * master -> next >> >> >> No other message mentions git branches that I could find, but I might >> have missed some instance. >> >> Now, there are more than one way to "move branches". The most natural >> is to merge your way forward, >> > Not in this case, as 'master' had several commits lacking in 'maint'. See below. >> in fact that's the only one that makes >> sense if the branches are *not* *rewindable*. >> >> Thinking about this for a few minutes, I think I would have (with >> better commit messages): >> # create 'next' >> $ git branch next master >> >> # update 'master' >> $ git branch new-master maint >> $ git checkout new-master >> $ git merge --strategy=ours master -m "rename maint -> master" >> > This would have obtained the wrong effect; what was in master before my > attempted renaming shouldn't have landed in the new 'master', but only > in 'next'. In the new 'master', we only wanted what was in the old 'maint'. The functional changes would not have appeared on the new branch (due to the 'ours' strategy), but yes, the commits would appear to be present on the new branch even if their corresponding changes would not, and I guess the generated ChangeLog would have been wrong too (listing changes that simply aren't there). The nice thing with assigning new roles using merges is that the history is transparent. It will show exactly what has happened for anyone that can be bothered to look. But as I said, I only thought about it for a few minutes... >> $ git checkout master >> $ git merge new-master # a simple fast-forward >> $ git branch -D new-master >> >> # update 'maint' >> $ git branch new-maint branch-1.13.2 >> $ git checkout new-maint >> $ git merge --strategy=ours maint -m "rename branch-1.13.2 -> maint" >> $ git checkout maint >> $ git merge new-maint # a simple fast-forward >> $ git branch -D new-maint >> > Same issue as above. Add these "abnormal" merges, and I think all would have been fine (apart from the generated ChangeLog mentioned above): $ git checkout master $ git merge --strategy=ours maint $ git checkout next $ git merge --strategy=ours master But, I don't actually think this branch restructuring was a good idea at all at this point in time. Branch reorganizations are better done in conjunction with a new major release. (BTW, if it was up to me, I would require a really good reason to ever release a 1.14, given that 1.14 looks like an old style major release, and has been mentioned multiple times on list, in commit messages and in code and tests. It's simply best if 1.14 never gets released). >> Forgive me for assuming that the branches would not be rewound. >> >> Also, I was away skiing last week, but I wouldn't have caught this >> even if I had been "present". >> >> BTW, I assume you could still use the mid part to update master, instead >> of waiting for the savannah crew to help you. >> > Of course, we don't need any help from Savannah, since, as I said, no > commit has been lost. If you want to revert the botched renaming, you > just need to rename the current 'maint' to 'branch-1.13.2', and recover > the previous 'maint' from the last merge into 'master' (that has not > been re-written), and delete the 'next' branch. What I meant was that you can use (some of) my above proposed merges to go forward with the new role for master instead of requiring help from Savannah to allow rewriting master. > As I said, if you reach a consensus on that (and I guess you will), > feel free to go ahead with that. No objection from me. You are the maintainer, I'm just stating my opinion. I honestly don't know what I think is best to do now, when the rewriting has already started but not yet completed. I guess it's your mess, and I don't really want to take responsibility for it by stepping in and trying to clear it up. I.e., I will only offer my opinion at this point. >> You just have to replace >> the first "git branch new-master ..." with >> >> $ git branch new-master b4dbcb75 >> >> (Because I think b4dbcb75 is what 'maint' was before you rewrote it.) > >>> >>> [BIG SNIP] >>> >>> OK, I thought about those considerations, but the situation seemed much >>> less bleak [SNIP] >> >> Why why why didn't you explain that in your rationale when proposing >> the change? If you truly wanted input, you should have stated the >> negatives as well in case someone had stronger reasons for being >> negative. >> > Because I mistakenly didn't think they were relevant negatives. So I simply don't get that, branch rewriting is just not something you inflict on your downstream (unless there truly is no other option, or if you have declared that you would up front). > new rule for me: from now on, all the negative sides I can think of > are relevant, no matter how tiny or even "irrelevant" they appear > to me. Cheers, Peter From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 23:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Nate Bargmann Cc: 13578@debbugs.gnu.org, automake@gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13620084438576 (code B ref 13578); Wed, 27 Feb 2013 23:41:02 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 23:40:43 +0000 Received: from localhost ([127.0.0.1]:54389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAqc4-0002EE-Q1 for submit@debbugs.gnu.org; Wed, 27 Feb 2013 18:40:43 -0500 Received: from mail-ee0-f48.google.com ([74.125.83.48]:37791) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAqby-0002Dy-Ab for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 18:40:35 -0500 Received: by mail-ee0-f48.google.com with SMTP id t10so962877eei.7 for <13578@debbugs.gnu.org>; Wed, 27 Feb 2013 15:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nYHE3u9rNM7dAuh9ks1z0lG5uOXCxkDkbMXBP/hfjAA=; b=kP++k4waH7arXwfk+Op5F2ipIeuiDCxjhlZkLl74sP8t2jl4uoqABez27TnfMPpJTg sNrRrt7inKVkNXZopWfiSeYwfXYRredBfP8L1+0IU3wHDObvJqmNNAqrN/W55BaWvzfW 22YfQud8WELlOKDg8Da2Hg4dTavzsXmxAKcPniQyawdx22LtZu2qtjocep+aMsp23pTg MTCqby4l6CVzcpTFuBHdwg4ZxWx6TRF0JcpiPboBTaTqnOAkO0oVq+Os5upSWYCbRKAc xpUZR+9RiESKPeEeb/FbxHD9o8H4bvgoPjUr989Dne8v6J/XVcLPkg15wR4laxbKXOPr V+hw== X-Received: by 10.14.179.194 with SMTP id h42mr10488405eem.46.1362008320570; Wed, 27 Feb 2013 15:38:40 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id a1sm8865419eep.2.2013.02.27.15.38.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 15:38:39 -0800 (PST) Message-ID: <512E98FD.1060705@gmail.com> Date: Thu, 28 Feb 2013 00:38:37 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> <20130227130738.GP31693@n0nb.us> In-Reply-To: <20130227130738.GP31693@n0nb.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) On 02/27/2013 02:07 PM, Nate Bargmann wrote: > > [SNIP] > >> Not in this case, as 'master' had several commits lacking in 'maint'. > > Would 'git cherry-pick' have worked? > No, because those commit were to be *dropped* (not added) from master; the old 'master' containing them was to be renamed to 'next'. > [SNIP] > > In other words, master contained commits intended for '2.0'+ (for > instance) that you didn't want in 1.13+, etc.? > Exactly. > Perhaps a new branch for > 1.13+ cut from some earlier commit in master and leaving master alone > would have worked? > What would have worked with minimal disruption would have been to keep the current names until the next major version (maybe just renaming 'branch-1.13.2' to 'fix' or 'micro' *after* the bug-fixing release); just after the new major release, 'fix', 'maint' and 'master' would have pointed to the *same* commit, so we could have juggled and swapped their names without causing any non-ff push. I thought the disruption of doing the renames right now would have been negligible anyway, but apparently I was badly wrong in that. > master would have then been consigned to being for > new development which isn't what you explicitly stated in the policy > above. I have to agree with Miles on the common assumption of the > master branch in Git as sort of a quasi-stable of the development tree. > So we should maybe go (after the next major release) with this naming scheme for the branches? * maint -> for next micro version * stable -> for next minor version * master -> for next major version > [SNIP] Thank, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 27 Feb 2013 23:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Peter Rosin Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13620084958663 (code B ref 13578); Wed, 27 Feb 2013 23:42:02 +0000 Received: (at 13578) by debbugs.gnu.org; 27 Feb 2013 23:41:35 +0000 Received: from localhost ([127.0.0.1]:54393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAqcw-0002Ff-Rv for submit@debbugs.gnu.org; Wed, 27 Feb 2013 18:41:35 -0500 Received: from mail-ee0-f50.google.com ([74.125.83.50]:38566) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAqcu-0002FX-P4 for 13578@debbugs.gnu.org; Wed, 27 Feb 2013 18:41:33 -0500 Received: by mail-ee0-f50.google.com with SMTP id e51so999457eek.37 for <13578@debbugs.gnu.org>; Wed, 27 Feb 2013 15:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=62XpEPnA9HDGItjFhi4AG/B3Y+H3m5d9UJd4LBtOa8I=; b=K7V+Z7LkdAlmJ6Gg+3Wi75IDbIKV1tY8BHrSPzTDKsNE1sIuwLOLTo2176pnHr/2nK RQsPcV6TyZNoQB1hk3ts9N7c8xZIesXIDkFrDdO8s2ZSgNEAyqn5vlxqK2Xq4YBhAwcR 837LS4bmSmro3pWNLORnwEdh2r3O+QtQ6sYbrvWEBEvh+Wu0RnP12PILhUEa+nd6KAaZ 1lFKk5t1oVYx/di/lw3cHUmY7/lIdL8lNpXLHS/WvKtXV2pyRKHEnXITKaeRxhTBCF0q 6LIbsLTEPmXgAA65Edsn1aCH1x67fa99IFc9gn39n+Uvk/fliIvlvThamKJCKXPkmvja NecA== X-Received: by 10.14.210.8 with SMTP id t8mr10658314eeo.35.1362008379048; Wed, 27 Feb 2013 15:39:39 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id m46sm8840273eeo.16.2013.02.27.15.39.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 15:39:38 -0800 (PST) Message-ID: <512E9938.1080604@gmail.com> Date: Thu, 28 Feb 2013 00:39:36 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> <512E8FF4.1090102@lysator.liu.se> In-Reply-To: <512E8FF4.1090102@lysator.liu.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/28/2013 12:00 AM, Peter Rosin wrote: > > [SNIP] > > What I meant was that you can use (some of) my above proposed merges > to go forward with the new role for master instead of requiring help > from Savannah to allow rewriting master. > So... now are you ok with *completing* my branch renaming instead of reverting the part of it that has already been done? Puzzled... >> As I said, if you reach a consensus on that (and I guess you will), >> feel free to go ahead with that. No objection from me. > > You are the maintainer, I'm just stating my opinion. I honestly don't > know what I think is best to do now, when the rewriting has already > started but not yet completed. I guess it's your mess, and I don't > really want to take responsibility for it by stepping in and trying > to clear it up. I.e., I will only offer my opinion at this point. > Fine, I'll revert the partial branch renaming when I have time to do that with enough care and attention to avoid another half-done botch-up (might be few days or a week or more; please don't push to the repo in the meantime). > [BIG SNIP] Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Peter Rosin Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 28 Feb 2013 08:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136203850422983 (code B ref 13578); Thu, 28 Feb 2013 08:02:02 +0000 Received: (at 13578) by debbugs.gnu.org; 28 Feb 2013 08:01:44 +0000 Received: from localhost ([127.0.0.1]:54955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAyQx-0005yd-Ne for submit@debbugs.gnu.org; Thu, 28 Feb 2013 03:01:44 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]:58917) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAyQu-0005yS-Kb for 13578@debbugs.gnu.org; Thu, 28 Feb 2013 03:01:41 -0500 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 709DE4000B; Thu, 28 Feb 2013 08:59:44 +0100 (CET) Received: from [192.168.0.64] (90-227-119-137-no95.business.telia.com [90.227.119.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 0E6C340005; Thu, 28 Feb 2013 08:59:44 +0100 (CET) Message-ID: <512F0E6F.8040803@lysator.liu.se> Date: Thu, 28 Feb 2013 08:59:43 +0100 From: Peter Rosin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> <512E8FF4.1090102@lysator.liu.se> <512E9938.1080604@gmail.com> In-Reply-To: <512E9938.1080604@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) On 2013-02-28 00:39, Stefano Lattarini wrote: > On 02/28/2013 12:00 AM, Peter Rosin wrote: >> >> [SNIP] >> >> What I meant was that you can use (some of) my above proposed merges >> to go forward with the new role for master instead of requiring help >> from Savannah to allow rewriting master. >> > So... now are you ok with *completing* my branch renaming instead > of reverting the part of it that has already been done? Puzzled... Personally, I will adapt to whatever you do. My objection was never about me personally, since I was aware of what took place and got clued in by your message about the troubles rewriting master. I am mostly just baffled that you even consider branch rewriting to be an option at all. If it weren't for the Savannah issues, I would probably have missed it, because I don't read automake-commit very carefully. Barring that "Savannah issues" mail, I would probably have first noticed the change when I pulled the next time (who knows when that would have happened, I don't pull the automake repo just for thrills). And I would have been extremely surprised by the failed merge during that pull. Who knows how many there are out there with a clone of the repo, but not following the mailing lists very carefully? Those are the ones I'm thinking about, and I think you should too. But since I'm not the maintainer, I will not have to face them when they have wasted time trying to figure out what has happened when their next pull fails. In other words, what to do next is your call. >>> As I said, if you reach a consensus on that (and I guess you will), >>> feel free to go ahead with that. No objection from me. >> >> You are the maintainer, I'm just stating my opinion. I honestly don't >> know what I think is best to do now, when the rewriting has already >> started but not yet completed. I guess it's your mess, and I don't >> really want to take responsibility for it by stepping in and trying >> to clear it up. I.e., I will only offer my opinion at this point. >> > Fine, I'll revert the partial branch renaming when I have time to do > that with enough care and attention to avoid another half-done botch-up > (might be few days or a week or more; please don't push to the repo in > the meantime). A second rewrite "undoing" (quotes here since the rewrite can't be undone, and me and probably others as well will have to adjust the local repo a second time) the first is probably the lesser evil, even if it is another branch rewrite. Cheers, Peter From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Miles Bader Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 28 Feb 2013 08:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Stefano Lattarini Cc: automake@gnu.org, Nate Bargmann , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136203928624156 (code B ref 13578); Thu, 28 Feb 2013 08:15:01 +0000 Received: (at 13578) by debbugs.gnu.org; 28 Feb 2013 08:14:46 +0000 Received: from localhost ([127.0.0.1]:54976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAyda-0006HY-03 for submit@debbugs.gnu.org; Thu, 28 Feb 2013 03:14:46 -0500 Received: from smtp11.dentaku.gol.com ([203.216.5.73]:38686) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UAydX-0006HO-0p for 13578@debbugs.gnu.org; Thu, 28 Feb 2013 03:14:44 -0500 Received: from 218.33.195.56.eo.eaccess.ne.jp ([218.33.195.56] helo=catnip.gol.com) by smtp11.dentaku.gol.com with esmtpa (Dentaku) (envelope-from ) id 1UAybc-0007IB-Lu; Thu, 28 Feb 2013 17:12:44 +0900 Received: by catnip.gol.com (Postfix, from userid 1000) id 66A1DDFC1; Thu, 28 Feb 2013 17:12:43 +0900 (JST) From: Miles Bader References: <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> <20130227130738.GP31693@n0nb.us> <512E98FD.1060705@gmail.com> System-Type: x86_64-unknown-linux-gnu Date: Thu, 28 Feb 2013 17:12:43 +0900 In-Reply-To: <512E98FD.1060705@gmail.com> (Stefano Lattarini's message of "Thu, 28 Feb 2013 00:38:37 +0100") Message-ID: <87ip5cj1qc.fsf@catnip.gol.com> Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) Stefano Lattarini writes: > So we should maybe go (after the next major release) with this naming > scheme for the branches? > > * maint -> for next micro version > * stable -> for next minor version > * master -> for next major version That seems to match common practice, insofar as I understand it... [Another consideration is whether you have a single named branch for maintenance (e.g. "maint", and "stable"), or just use version-named branches (and thus can maintain multiple versions simultaneously).] -miles -- Future, n. That period of time in which our affairs prosper, our friends are true and our happiness is assured. From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Russ Allbery Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 28 Feb 2013 13:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: automake@gnu.org, 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.136205857625479 (code B ref 13578); Thu, 28 Feb 2013 13:37:01 +0000 Received: (at 13578) by debbugs.gnu.org; 28 Feb 2013 13:36:16 +0000 Received: from localhost ([127.0.0.1]:55437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UB3eh-0006cu-O2 for submit@debbugs.gnu.org; Thu, 28 Feb 2013 08:36:16 -0500 Received: from smtp2.stanford.edu ([171.67.219.82]:42389 helo=smtp.stanford.edu) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UB3ee-0006cl-AV for 13578@debbugs.gnu.org; Thu, 28 Feb 2013 08:36:14 -0500 Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 81B3C6467EB; Thu, 28 Feb 2013 05:34:15 -0800 (PST) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id B586C6466EC; Thu, 28 Feb 2013 05:34:14 -0800 (PST) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9EACE2F431; Thu, 28 Feb 2013 05:34:14 -0800 (PST) From: Russ Allbery In-Reply-To: <87ip5cj1qc.fsf@catnip.gol.com> (Miles Bader's message of "Thu, 28 Feb 2013 17:12:43 +0900") Organization: The Eyrie References: <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> <20130227130738.GP31693@n0nb.us> <512E98FD.1060705@gmail.com> <87ip5cj1qc.fsf@catnip.gol.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Thu, 28 Feb 2013 05:34:14 -0800 Message-ID: <87hakwbm09.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.2 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) I want to preface this by noting that I think this is really much ado about nothing. I've done these sorts of non-rewindable branch renamings before, and while they're mildly annoying, it's pretty rare that there are tons of people out there with Git clones that aren't following the development mailing list and get somehow confused. It's just not that big of a deal; basically everyone who has bothered to clone your Git repository for the typical smallish project (and Automake, despite being very widely used, is from a development perspective a smallish project) is following the mailing list anyway and will see the instructions. Also, those of us who have been using Git for a while will have run into this before and will have some idea of how to deal with it. And, failing that, even if one can't figure out the right way to manipulate one's local repository to prepare, there's always the hammer approach of git format-patch to generate whatever local changes one has, cloning a new repository, and git am to put them back, which really isn't that big of a deal. Therefore, I think whoever is active in development should basically just do whatever they want to do and the rest of us will cope. I think it's way more important that the primary developers be comfortable with the setup (and not feel demotivated by having to argue about it) than any particular scheme of Git purity be adopted. That said, if and only if the folks who are mostly doing the work are interested in the more theoretical discussion of possible schemes.... Miles Bader writes: > Stefano Lattarini writes: >> So we should maybe go (after the next major release) with this naming >> scheme for the branches? >> >> * maint -> for next micro version >> * stable -> for next minor version >> * master -> for next major version > That seems to match common practice, insofar as I understand it... > [Another consideration is whether you have a single named branch for > maintenance (e.g. "maint", and "stable"), or just use version-named > branches (and thus can maintain multiple versions simultaneously).] I'd say that the latter (using separate branches for each version) is the most common. One other advantage is that if you don't have any changes that need to be restricted to a particular scope, you don't bother creating the branch. So, you start with just: master -> for next major version plus of course tags for each release. At the point at which you have a change that should go into the next minor version and a change that should *not* go into the next minor version (in other words, at the point at which the maintenance diverges), you create a new branch: stable-2 (for maintenance of version 2.* for example) make the change on that branch and merge that branch to master. (Or make the change on master and cherry-pick it to the branch, but it's always nice to merge the stable branch onto master to be sure you didn't miss anything.) Since it's quite likely that you'll want this level of branching, it's of course reasonable to make this branch proactively. You make minor and micro releases for version 2.* from that branch up until the point at which there's something that needs to go into the micro release and other changes that shouldn't, at which point you might create: stable-2.1 (for example) to manage further 2.1.* micro releases. Many projects never need that last level of branching. I suspect you'll find that you will use it once or twice but not as a systematic practice. Usually, it's easier to just make releases from the stable branch and version them (either minor or micro) according to the nature of the changes that have accumulated. -- Russ Allbery (rra@stanford.edu) From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 05 Mar 2013 14:36:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Peter Rosin Cc: Automake List , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13624941343238 (code B ref 13578); Tue, 05 Mar 2013 14:36:03 +0000 Received: (at 13578) by debbugs.gnu.org; 5 Mar 2013 14:35:34 +0000 Received: from localhost ([127.0.0.1]:60037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCsxo-0000q8-S6 for submit@debbugs.gnu.org; Tue, 05 Mar 2013 09:35:33 -0500 Received: from mail-wg0-f51.google.com ([74.125.82.51]:47254) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCsxe-0000pm-A1 for 13578@debbugs.gnu.org; Tue, 05 Mar 2013 09:35:27 -0500 Received: by mail-wg0-f51.google.com with SMTP id 8so5905890wgl.30 for <13578@debbugs.gnu.org>; Tue, 05 Mar 2013 06:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9UfCtmcvEUBjxBQ3KLK10tuFcQ6sXHiEQB9s9VODaSo=; b=OpmntUHWWxJlnqWJCJrFHcljPwvnGpbVGc4bLptYWHkN8BnygiFpI50AIqzX3jxuNL TMlhSP7qQhrSIJBEnZ9QL1gwwWqWEVPni74ld6TL+U1lvrd18dDG4v277w8krBLs3BEa JMqIQwDsXX+jI0anRnSm2GvkUZr4sMmXEgBh7PtAytkNXBbkrAodWJuPcb/53e0MoIso rANsR4lo1BY7tUycLCjKd+X2Ti7ONhVFSUtlSbwyZSV3t5TBYF7qgk7Wngm4ALYTy7zv rTS0gGB5qbf5muXW12YG0JKI0G8X8oRN8cxMYrmsrWlYCRwG1AnGHGxCrZI65bwrZanb moTA== X-Received: by 10.205.136.205 with SMTP id il13mr9293398bkc.93.1362494095732; Tue, 05 Mar 2013 06:34:55 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id x18sm7176982bkw.4.2013.03.05.06.34.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 06:34:54 -0800 (PST) Message-ID: <5136028C.1090004@gmail.com> Date: Tue, 05 Mar 2013 15:34:52 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <5106D62B.6070007@gmail.com> <511BDDDD.2040904@gmail.com> <5120EFE9.30200@gmail.com> <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> <512E8FF4.1090102@lysator.liu.se> <512E9938.1080604@gmail.com> <512F0E6F.8040803@lysator.liu.se> In-Reply-To: <512F0E6F.8040803@lysator.liu.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/28/2013 08:59 AM, Peter Rosin wrote: > > [SNIP] > > A second rewrite "undoing" (quotes here since the rewrite can't be > undone, and me and probably others as well will have to adjust the > local repo a second time) the first is probably the lesser evil, > even if it is another branch rewrite. > It should be done now. Please check the repository really is in a correct state. Regards, Stefano From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: [IMPORTANT] Savannah issues Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 05 Mar 2013 14:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Miles Bader Cc: automake@gnu.org, Nate Bargmann , 13578@debbugs.gnu.org Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.13624941673315 (code B ref 13578); Tue, 05 Mar 2013 14:37:01 +0000 Received: (at 13578) by debbugs.gnu.org; 5 Mar 2013 14:36:07 +0000 Received: from localhost ([127.0.0.1]:60041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCsyK-0000rD-4J for submit@debbugs.gnu.org; Tue, 05 Mar 2013 09:36:06 -0500 Received: from mail-wg0-f44.google.com ([74.125.82.44]:45343) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCsyH-0000qo-Cx for 13578@debbugs.gnu.org; Tue, 05 Mar 2013 09:36:02 -0500 Received: by mail-wg0-f44.google.com with SMTP id dr12so5825015wgb.35 for <13578@debbugs.gnu.org>; Tue, 05 Mar 2013 06:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OaEpkTCrIgO1Y/s7cCGalocQoPLOGkhYKfWWiYX02Lc=; b=hJfb8c/8T+d0PdK/b8/bUperjXvbhXWuLlFSgdRG+ZNt65bBlu7B0KZIW57yOFPmBc oZwsD1QknZli5SGBD6OEzuPOV4X66ePE1U4DN5gqIUokOU16h2Hs5VSfEvM5oKwNV73L BPL/DJ8KSNWmB/abX+YZVjDCrS4eKysgbaae38JNeDykGfketPKiKWUsiYkiR+d1DfUq pPXl2/M8eZ16O7ik1ylKUaEVs4Z3sEzFLutF8TNsTNKDXZTQ0db6NmDrhjCSjG8edjJO x4KiGA6H5pDwZMesuT0V5C4VuF8APPbzLjqDwZM6vQsDtDWqqqi+Xjj5kW+I0AYi8JSs 3qvA== X-Received: by 10.204.147.81 with SMTP id k17mr9464476bkv.70.1362494135035; Tue, 05 Mar 2013 06:35:35 -0800 (PST) Received: from [192.168.178.20] (host137-94-dynamic.4-87-r.retail.telecomitalia.it. [87.4.94.137]) by mx.google.com with ESMTPS id gu14sm7178552bkc.1.2013.03.05.06.35.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 06:35:34 -0800 (PST) Message-ID: <513602B3.6030303@gmail.com> Date: Tue, 05 Mar 2013 15:35:31 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <51262FEE.5030509@gmail.com> <51263803.6020605@gmail.com> <5129007E.3050609@gmail.com> <51290516.2080607@gmail.com> <512B1D50.5080201@lysator.liu.se> <512B2C06.6000403@gmail.com> <512BF967.1040701@lysator.liu.se> <512CFF36.4010506@gmail.com> <512DD1D8.20303@lysator.liu.se> <512DE017.50505@gmail.com> <20130227130738.GP31693@n0nb.us> <512E98FD.1060705@gmail.com> <87ip5cj1qc.fsf@catnip.gol.com> In-Reply-To: <87ip5cj1qc.fsf@catnip.gol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 02/28/2013 09:12 AM, Miles Bader wrote: > Stefano Lattarini writes: >> So we should maybe go (after the next major release) with this naming >> scheme for the branches? >> >> * maint -> for next micro version >> * stable -> for next minor version >> * master -> for next major version > > That seems to match common practice, insofar as I understand it... > OK, I don't dislike this naming scheme, so I will implement it once 1.14 has been released (at that point, we'll be able to do so without having to resort to non-fast-forward pushes). That might take an undetermined time between a couple of months and forever. I have no intention of discussing further the bike-shedding of branch naming, so this naming scheme will be the one we'll use, period. > [Another consideration is whether you have a single named branch for > maintenance (e.g. "maint", and "stable"), or just use version-named > branches (and thus can maintain multiple versions simultaneously).] > The former, I only want to have one maintenance branch. Having several for older versions is just too work for no real gain (and if a security fix is needed, bug-fixing branches for several old releases can just be created on demand without anu fuss). Thanks for the feedback, and best regards, Stefano From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 19:46:32 2017 Received: (at control) by debbugs.gnu.org; 16 Jun 2017 23:46:32 +0000 Received: from localhost ([127.0.0.1]:51831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM0wi-0002iX-D3 for submit@debbugs.gnu.org; Fri, 16 Jun 2017 19:46:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40765) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM0wg-0002XG-Py for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:46:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dM0wS-0008CW-Nn for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:46:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dM0wS-0008CL-K5 for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:46:16 -0400 Received: from [2a01:e35:2ec2:e580:491c:541:7a4a:37d9] (port=43490 helo=localhost.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dM0wS-0005oT-2r for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:46:16 -0400 Date: Sat, 17 Jun 2017 01:46:08 +0200 Message-Id: <87efujpkcf.fsf@gnu.org> To: control@debbugs.gnu.org From: Mathieu Lirzin Subject: control message for bug #13578 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.4 (---) unarchive 13578 From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 19:55:10 2017 Received: (at control) by debbugs.gnu.org; 16 Jun 2017 23:55:10 +0000 Received: from localhost ([127.0.0.1]:51836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM154-0003Xo-9K for submit@debbugs.gnu.org; Fri, 16 Jun 2017 19:55:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM152-0003XU-8g for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:55:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dM14w-0007YN-7t for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:55:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dM14w-0007YI-4Z for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:55:02 -0400 Received: from [2a01:e35:2ec2:e580:491c:541:7a4a:37d9] (port=43510 helo=localhost.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dM14v-0006CE-KJ for control@debbugs.gnu.org; Fri, 16 Jun 2017 19:55:01 -0400 From: Mathieu Lirzin To: control-debbugs-gnu Subject: control message for bug #13578 Date: Sat, 17 Jun 2017 01:55:00 +0200 Message-ID: <87bmpnpjxn.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.4 (---) submitter 13578 mthl@gnu.org thanks -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: Status: A new versioning scheme for automake releases, and a new branching scheme for the Git repository References: <5106D62B.6070007@gmail.com> Resent-From: Mathieu Lirzin Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Sat, 17 Jun 2017 01:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: bug#13578 <13578@debbugs.gnu.org> Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.149766220827799 (code B ref 13578); Sat, 17 Jun 2017 01:17:01 +0000 Received: (at 13578) by debbugs.gnu.org; 17 Jun 2017 01:16:48 +0000 Received: from localhost ([127.0.0.1]:51867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM2M4-0007EJ-CH for submit@debbugs.gnu.org; Fri, 16 Jun 2017 21:16:48 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM2M3-0007E6-2w for 13578@debbugs.gnu.org; Fri, 16 Jun 2017 21:16:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dM2Lw-0007fZ-QU for 13578@debbugs.gnu.org; Fri, 16 Jun 2017 21:16:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_50,FAKE_REPLY_C, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dM2Lw-0007fU-Mx for 13578@debbugs.gnu.org; Fri, 16 Jun 2017 21:16:40 -0400 Received: from [2a01:e35:2ec2:e580:491c:541:7a4a:37d9] (port=43604 helo=localhost.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dM2Lw-0002Be-1o for 13578@debbugs.gnu.org; Fri, 16 Jun 2017 21:16:40 -0400 From: Mathieu Lirzin Date: Sat, 17 Jun 2017 03:16:38 +0200 In-Reply-To: bug's message of "Sat\, 17 Jun 2017 00\:05\:28 +0000" Message-ID: <87vanvo1l5.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.4 (---) Hello, As the new maintainer, I would like to change the branch naming convention to make the life of casual contributors easier. The issue is that when someone clone the Automake repository, it defaults to the "master" branch which is a "not ready to be released" development branch and not a particularly active one (I mean less active than the other ;)). Right now we are using this branch naming scheme: - micro: for next micro version - minor: for next minor version - master: for next major version Given the current state of Automake I consider that the main scenario for contributing to Automake is either fixing a bug or developping an additional feature ontop of the current release version (1.15). As a consequence the current branching scheme requires newcomers to read through the HACKING file to understand that they have to base their work either on the "micro" or "minor" branch. One solution would be to change the default branch used when cloning the repository, but that would look weird on its own to have a default not named "master" given the fact that it is a well accepted default. As a consequence I am not considering it. What I am proposing is the following branch name scheme: - master: for the next version to be released (currently a minor version) - maint: for the previous releases (major or minor) merged from master and their bug fixing commits leading to a micro version release. - next: for the "not ready to be release" Automake 2.0 that should be merged in master when ready (if ever) My reasoning is that developping a feature branche should be based on the code that will appear in the next release by default, and in the case of bugs if someone find one on the previous release it is highly probable that it is still reproducible in the next coming release unless it has already been fixed. Unless there are better suggestions or valid objections proposed in the following week, I will send a request to the Savannah administrators to apply the following renaming: - master -> next - minor -> master - micro -> maint Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 From unknown Sun Jun 22 08:00:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13578: Status: A new versioning scheme for automake releases, and a new branching scheme for the Git repository Resent-From: Mathieu Lirzin Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 19 Sep 2017 23:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13578 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: bug#13578 <13578@debbugs.gnu.org> Cc: Automake-patches , Automake Received: via spool by 13578-submit@debbugs.gnu.org id=B13578.15058625953378 (code B ref 13578); Tue, 19 Sep 2017 23:10:02 +0000 Received: (at 13578) by debbugs.gnu.org; 19 Sep 2017 23:09:55 +0000 Received: from localhost ([127.0.0.1]:48808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duReM-0000sQ-OC for submit@debbugs.gnu.org; Tue, 19 Sep 2017 19:09:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duReK-0000sD-3n for 13578@debbugs.gnu.org; Tue, 19 Sep 2017 19:09:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duReD-0002t3-MX for 13578@debbugs.gnu.org; Tue, 19 Sep 2017 19:09:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duRe8-0002pZ-PL; Tue, 19 Sep 2017 19:09:40 -0400 Received: from [2a01:e35:2ec2:e580:491c:541:7a4a:37d9] (port=35864 helo=localhost.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1duRe8-0008Ah-9s; Tue, 19 Sep 2017 19:09:40 -0400 From: Mathieu Lirzin References: <5106D62B.6070007@gmail.com> <87vanvo1l5.fsf@gnu.org> Date: Wed, 20 Sep 2017 01:09:37 +0200 In-Reply-To: <87vanvo1l5.fsf@gnu.org> (Mathieu Lirzin's message of "Sat, 17 Jun 2017 03:16:38 +0200") Message-ID: <87efr2nv4e.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hello, Mathieu Lirzin writes: > Right now we are using this branch naming scheme: > > - micro: for next micro version > - minor: for next minor version > - master: for next major version > > Given the current state of Automake I consider that the main scenario > for contributing to Automake is either fixing a bug or developping an > additional feature ontop of the current release version (1.15). As a > consequence the current branching scheme requires newcomers to read > through the HACKING file to understand that they have to base their work > either on the "micro" or "minor" branch. > [...] > What I am proposing is the following branch name scheme: > > - master: for the next version to be released (currently a minor version) > - maint: for the previous releases (major or minor) merged > from master and their bug fixing commits leading to a micro > version release. > - next: for the "not ready to be release" Automake 2.0 that should > be merged in master when ready (if ever) > > Unless there are better suggestions or valid objections proposed in the > following week, I will send a request to the Savannah administrators to > apply the following renaming: > > - master -> next > - minor -> master > - micro -> maint After doing that request to the Savannah administrators which has not been answered after more than 2 months [1]. I have decided to proceed with the the branch renaming myself by resetting the 'master' branch and then merging 'minor' into 'master' manually. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 [1] https://lists.gnu.org/archive/html/savannah-hackers/2017-07/msg00002.html From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 19 19:10:02 2017 Received: (at control) by debbugs.gnu.org; 19 Sep 2017 23:10:02 +0000 Received: from localhost ([127.0.0.1]:48811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duReU-0000sw-2s for submit@debbugs.gnu.org; Tue, 19 Sep 2017 19:10:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43651) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duReT-0000sY-3y for control@debbugs.gnu.org; Tue, 19 Sep 2017 19:10:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duReN-00030b-Af for control@debbugs.gnu.org; Tue, 19 Sep 2017 19:09:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duReN-00030W-7U for control@debbugs.gnu.org; Tue, 19 Sep 2017 19:09:55 -0400 Received: from [2a01:e35:2ec2:e580:491c:541:7a4a:37d9] (port=35866 helo=localhost.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1duReM-0008Cj-OI for control@debbugs.gnu.org; Tue, 19 Sep 2017 19:09:55 -0400 Date: Wed, 20 Sep 2017 01:09:53 +0200 Message-Id: <87d16mnv3y.fsf@gnu.org> To: control@debbugs.gnu.org From: Mathieu Lirzin Subject: control message for bug #13578 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) tags 13578 fixed close 13578