From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Date: Wed, 29 Sep 2004 12:46:39 -0500 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <87hdphx91c.fsf@trouble.defaultvalue.org> References: <1096291271.415813c757a26@imp6-q.free.fr> <20040927134714.GA20012@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096480111 30691 80.91.229.6 (29 Sep 2004 17:48:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Sep 2004 17:48:31 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, Stefan Monnier , J?r?me Marant , "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 29 19:48:16 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CCiYq-0000E3-00 for ; Wed, 29 Sep 2004 19:48:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCifC-0003rr-Br for ged-emacs-devel@m.gmane.org; Wed, 29 Sep 2004 13:54:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CCif5-0003rB-Mx for emacs-devel@gnu.org; Wed, 29 Sep 2004 13:54:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CCif4-0003qm-VF for emacs-devel@gnu.org; Wed, 29 Sep 2004 13:54:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCif4-0003qj-4n for emacs-devel@gnu.org; Wed, 29 Sep 2004 13:54:42 -0400 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CCiYZ-0000br-2c; Wed, 29 Sep 2004 13:47:59 -0400 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id 25C7F3FB1; Wed, 29 Sep 2004 12:47:58 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id C365C410A1; Wed, 29 Sep 2004 12:46:39 -0500 (CDT) Original-To: Miles Bader In-Reply-To: <20040927134714.GA20012@fencepost> (Miles Bader's message of "Mon, 27 Sep 2004 09:47:14 -0400") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27673 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27673 Miles Bader writes: > I think it's a great idea if it starts from 21.4 like you said. So I'm wondering a little about the details. From some other projects, I'm used to an aproach where an X.Y.0 (or just X.Y) release is a "major" release, one which might break things, might have "more adventurous" changes in it, and might not happen very frequently , and an X.Y.Z (for Z > 0) release is just a bugfix release, which is made "as often as needed". (Of course, X.0.0 releases would represent an even bigger change than X.Y.0 releases.) In the above scenario, whenever an X.Y.0 release is made, an X.Y branch would be created for work on subsequent X.Y.Z releases. However, from some of the discussion, I'm not sure this maps as directly to the Emacs development process as I'd first thought. Just to make sure what we've been proposing is clear -- if this proposal had been implemented with the 23.1 release, then rather than just backporting fixes into the Debian tree, Jerome and I would have been backporting those fixes into a new branch created during the 23.1 release, and then would have released 23.1.1, 23.1.2, etc. from there. It would also be important to try to be careful that the changes to the bugfix branch are minimal and uncontroversial (i.e. bug fixes rather than giant patches with new features), so that the divergence from the mainstream development branch is minimized, and so that it's not likely that a new point-release would cause unintentional new breakage. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4