From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: next emacs version? Date: Sat, 20 Mar 2010 01:31:28 -0400 Message-ID: <11D537FD-7D31-43A9-BD43-8F734576F0EC@raeburn.org> 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 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1269063208 19334 80.91.229.12 (20 Mar 2010 05:33:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 20 Mar 2010 05:33:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 20 06:33:23 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 1NsrJF-0007q6-Sk for ged-emacs-devel@m.gmane.org; Sat, 20 Mar 2010 06:33:18 +0100 Original-Received: from localhost ([127.0.0.1]:47296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NsrJF-00076A-8Y for ged-emacs-devel@m.gmane.org; Sat, 20 Mar 2010 01:33:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NsrHq-0006dX-QG for emacs-devel@gnu.org; Sat, 20 Mar 2010 01:31:50 -0400 Original-Received: from [140.186.70.92] (port=57212 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NsrHp-0006dE-GS for emacs-devel@gnu.org; Sat, 20 Mar 2010 01:31:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NsrHo-0006Ax-0D for emacs-devel@gnu.org; Sat, 20 Mar 2010 01:31:49 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:44670 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NsrHW-00069h-8A for emacs-devel@gnu.org; Sat, 20 Mar 2010 01:31:47 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o2K5VSIx024595; Sat, 20 Mar 2010 01:31:28 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:122342 Archived-At: On Mar 19, 2010, at 23:38, Drew Adams wrote: >> If you need discrete points in time where you can distinguish "fixed=20= >> before" from "fixed after", that's what releases are for. >=20 > The granularity is too gross. >=20 >> If you (=3D> users of your, Drew's, code) want to experiment with=20 >> development versions, it shouldn't be too much to ask for you=20 >> to keep fairly current, or at least update before complaining=20 >> about bugs. >=20 > It's not about bugs or keeping current. The user in question ("you") = had the > very latest BZR code in his build. >=20 > 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. If you insist that they keep current (or more specifically, that the = only dev version you'll support is the current one, when you support any = dev version at all), you shouldn't need anything more fine-grained than = "release X" or "dev version leading up to release Y", should you? I = think I'm confused about whether you're trying to support people running = outdated dev versions. >> (And if you want to ship non-released development versions to >> your friends or customers, you're on your own.) >=20 > I guess "you" here is back to meaning me, rather than users of my = code. Or anyone redistributing emacs in a software distribution, maintaining a = local installation for a site, etc. Thinking back to the gcc-2.96 mess, = where there was no official release with that number, but lots of people = wound up running something identifying itself that way anyways. > 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. When you do this, do you also try to keep it working with the earlier = development versions? Or is it okay to break things for = dev-from-last-month as long as 23.1 and dev-from-this-month both still = work? If the changes are easy enough to identify, supporting all of them is = great. But if they're too difficult to identify without resorting to = version numbers, is it really that important to support (in effect) = multiple dev versions rather than just the latest (at this point, = perhaps along both of the next-minor-release and next-major-release = branches)? Ken=