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: next emacs version? Date: Tue, 23 Mar 2010 11:34:34 +0900 Message-ID: <878w9jix51.fsf@uwakimon.sk.tsukuba.ac.jp> References: <56D10E2523764AC98D99CEBC55DBAD93@us.oracle.com> <83iq8sigyq.fsf@gnu.org> <83d3z0i3nu.fsf@gnu.org> <911BA1D06CEB4306924D0069BA2D3DFF@us.oracle.com> <83bpeki18a.fsf@gnu.org> <83aau4hv38.fsf@gnu.org> <0E10B96B5C814EE8B95B57972F13E189@us.oracle.com> <5E984B3C-4B86-4FA6-8675-4C8501CC2285@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269311817 20318 80.91.229.12 (23 Mar 2010 02:36:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Mar 2010 02:36:57 +0000 (UTC) Cc: 'Ken Raeburn' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 23 03:36:53 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NttzA-0005Zc-Cr for ged-emacs-devel@m.gmane.org; Tue, 23 Mar 2010 03:36:52 +0100 Original-Received: from localhost ([127.0.0.1]:50245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nttz9-0007Ly-EO for ged-emacs-devel@m.gmane.org; Mon, 22 Mar 2010 22:36:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NttyR-00076y-Kx for emacs-devel@gnu.org; Mon, 22 Mar 2010 22:36:07 -0400 Original-Received: from [140.186.70.92] (port=47910 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NttyP-00076C-QW for emacs-devel@gnu.org; Mon, 22 Mar 2010 22:36:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NttyN-0006Zy-Ub for emacs-devel@gnu.org; Mon, 22 Mar 2010 22:36:05 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:43400) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NttyN-0006Zq-Fu for emacs-devel@gnu.org; Mon, 22 Mar 2010 22:36:03 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id AC7921535A8; Tue, 23 Mar 2010 11:36:02 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4143B1A3800; Tue, 23 Mar 2010 11:34:34 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122523 Archived-At: Drew Adams writes: > > If you need discrete points in time where you can distinguish "fixed > > before" from "fixed after", that's what releases are for. > > The granularity is too gross. Too bad. There's no good way to linearize the whole DAG for your purpose. Dates won't work because parallel branches will not necessarily merge a given change at the same time. The approximation used is for the Emacs developers to agree on a conventional ordering, which is called "the mainline". If you know your user is "on the mainline", then dates can be used to do the ordering, or the revision number. The problem with the revision number, though, is that in general it is unstable (the same revision will be numbered differently in different workspaces, depending on which branch they are derived from). Note that pragmatically the reason for using releases as markers is that socially the project (except for a very few long-lived branches, and the special "pending" branch, which may be used by users who should be assumed to know what they're doing) converges to a *single* point of agreement. After a release, things get fuzzy. And if your users are using the pending branch, or a feature branch (such as Eli's bidi or Miles's lexbind), all bets are off. You really should just tell those folks it's *their* problem. After all, that's what they asked for by using bleeding edge branches. > In practice, many large changes do involve some change that is > readily identifiable (e.g a new fn). In the case in point, the code > change was small (a new regexp value) but the change in effect was > not so small (use of the regexp for font-locking). Grin and bear it, man. On this one, you lose. You are not going to get the fine-grained test you want. The exact form of that test is to trace back in bzr's DAG for the build to determine whether the revision that introduced the change is an ancestor of this build. (And even that's not good enough, because it might get reverted or "perverted" by a later change that you'd have to test for.) For your purpose here, you can test the regexp value (or even force it to one you can deal with). Or you can test for release order and tell users that "between these two releases you're out of luck." > This is a common occurrence/predicament. I (and I assume others > too) sometimes get bug reports for my libraries that really amount > to Emacs dev changes "breaking" things. Much of the time my answer > must be "Too bad. I don't support ongoing Emacs development. Wait > until the next Emacs release". What's the problem? That is the correct answer (modulo the addition of "patches that work before and after the Emacs change welcome", if appropriate for your development policy).