From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Moving Emacs 24.3 development to emacs-24 branch soon Date: Fri, 02 Nov 2012 01:32:29 +0900 Message-ID: <87bofhjnc2.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87txtajclb.fsf@gnu.org> <83d2zx77ub.fsf@gnu.org> <874nl95ss4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1351788268 20074 80.91.229.3 (1 Nov 2012 16:44:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2012 16:44:28 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 01 17:44:37 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TTxsh-0000OP-2t for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2012 17:44:35 +0100 Original-Received: from localhost ([::1]:37402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTxsY-00063R-J3 for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2012 12:44:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTxsW-00062m-76 for emacs-devel@gnu.org; Thu, 01 Nov 2012 12:44:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTxsT-0005Ax-QX for emacs-devel@gnu.org; Thu, 01 Nov 2012 12:44:24 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:37561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTxh7-0002Cz-M7; Thu, 01 Nov 2012 12:32:37 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7CBE49708EC; Fri, 2 Nov 2012 01:32:29 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 428DC1A3487; Fri, 2 Nov 2012 01:32:29 +0900 (JST) In-Reply-To: <874nl95ss4.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154617 Archived-At: Chong Yidong writes: > As Stefan pointed out to me in a separate email, pushing will work, one > just has to set the bzr configuration variable append_revisions_only to > False. The bzr tag doesn't seem to be discarded by the push, either; it > is still possible to check it out with -r TAGNAME afterward. Just because you can do it doesn't mean you should. It is best current practice, accepted in many projects, to make a branch for each feature release. The primary rationale (keeping bugfix and security releases in different release branches from stepping on each other, and keeping feature code from accidentally leaking across releases) doesn't apply to Emacs since Emacs only supports one release at a time. Nevertheless, third parties do maintain such branches for various reasons. Things are simpler for everybody if each release has its own branch. Rebasing also theoretically messes up the bloodlines. The code in the 24.3 release is *not* a child of the 24.2 release, it is a sibling. The rebase ends up unnecessarily duplicating all the history on the trunk in the branch. If you have some specific benefit of rebasing onto the existing minor release branch, OK, I don't see a *high* probability of *serious* trouble from doing it. But I don't really see any benefit from it, except preserving a formal linearity of the 24.x branch, which doesn't reflect the way development actually occurred. Steve