From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: next emacs version? Date: Fri, 19 Mar 2010 20:38:17 -0700 Message-ID: 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" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1269056377 6368 80.91.229.12 (20 Mar 2010 03:39:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 20 Mar 2010 03:39:37 +0000 (UTC) To: "'Ken Raeburn'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 20 04:39:33 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 1NspWn-0003Mz-Oy for ged-emacs-devel@m.gmane.org; Sat, 20 Mar 2010 04:39:10 +0100 Original-Received: from localhost ([127.0.0.1]:59138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NspWm-0005eb-To for ged-emacs-devel@m.gmane.org; Fri, 19 Mar 2010 23:39:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NspWi-0005eW-9p for emacs-devel@gnu.org; Fri, 19 Mar 2010 23:39:04 -0400 Original-Received: from [140.186.70.92] (port=59160 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NspWg-0005eO-66 for emacs-devel@gnu.org; Fri, 19 Mar 2010 23:39:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NspWe-0006gk-Hr for emacs-devel@gnu.org; Fri, 19 Mar 2010 23:39:02 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:24670) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NspWe-0006ge-Cn for emacs-devel@gnu.org; Fri, 19 Mar 2010 23:39:00 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2K3cvKe008276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Mar 2010 03:38:58 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2K3ctVP015148; Sat, 20 Mar 2010 03:38:56 GMT Original-Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 101989961269056297; Fri, 19 Mar 2010 20:38:17 -0700 Original-Received: from dradamslap1 (/24.5.179.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Mar 2010 20:38:16 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5E984B3C-4B86-4FA6-8675-4C8501CC2285@raeburn.org> Thread-Index: AcrH1hyVD5I9TPHiRhOixDw3Njdr7AABGvMw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BA44350.01CF:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:122334 Archived-At: > > OK in this particular case, but the general question > > remains. If this change had been made in a 23.0.50.1 dev version > > (or whatever the nomenclature is), then some such dev versions > > would have the change and some would not. > > Unless you want to start putting bzr revision numbers into > the emacs version string (which I think is a bad idea), Agreed; a bad idea. > that's going to be the case. Version numbers like 23.0.50.1 > apply to a long string of development revisions. Yes, that was my understanding. > 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. > If you (=> users of your, Drew's, code) want to experiment with > development versions, it shouldn't be too much to ask for you > to keep fairly current, or at least update before complaining > about bugs. It's not about bugs or keeping current. The user in question ("you") had the very latest BZR code in his build. The point is that whereas it is typically simple to support fine-grained differences when a change adds a variable or function (use boundp or fboundp), other kinds of changes are not so easily identified. 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). > (And if you want to ship non-released development versions to > your friends or customers, you're on your own.) I guess "you" here is back to meaning me, rather than users of my code. No, I don't ship Emacs versions of any kind. And I generally don't try to support Emacs development versions in my libraries. Instead, I wait until the next release to update my code. But sometimes (esp. if the release cycle is long) I do make changes (esp. if minor) that allow my code to keep working with the latest development version. That's sometimes easy when it concerns a new var or fn (but not arity change etc. for a fn). Otherwise, it is usually impractical. A case in point: changes to info.el immediately after the 23.1 release. I did update my code to accommodate those changes, to allow users to keep using my code. Otherwise, their only choice is to either forego using my library until the next release or forego using the latest (dev) Emacs. But in general trying to keep up with Emacs dev changes is something I avoid, even if users would prefer to keep up-to-date with Emacs dev and still have their 3rd-party code also work. 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".