From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Guile release planning Date: Sun, 16 Nov 2008 00:03:05 +0000 Message-ID: <49dd78620811151603t67745c6fy7eb8b5134f883521@mail.gmail.com> References: <49dd78620811101723m6b014589ua01037d5ea3f17b9@mail.gmail.com> <87prl2m2du.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1226793813 18839 80.91.229.12 (16 Nov 2008 00:03:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2008 00:03:33 +0000 (UTC) Cc: guile-user@gnu.org, guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Nov 16 01:04:35 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L1V7y-0003gV-CS for guile-user@m.gmane.org; Sun, 16 Nov 2008 01:04:35 +0100 Original-Received: from localhost ([127.0.0.1]:33674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1V6q-0003KL-Au for guile-user@m.gmane.org; Sat, 15 Nov 2008 19:03:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1V6b-0003K4-2v for guile-user@gnu.org; Sat, 15 Nov 2008 19:03:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1V6a-0003Jl-IM for guile-user@gnu.org; Sat, 15 Nov 2008 19:03:08 -0500 Original-Received: from [199.232.76.173] (port=54965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1V6a-0003Jh-Ed for guile-user@gnu.org; Sat, 15 Nov 2008 19:03:08 -0500 Original-Received: from rv-out-0708.google.com ([209.85.198.250]:40791) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L1V6Z-0003op-OK for guile-user@gnu.org; Sat, 15 Nov 2008 19:03:08 -0500 Original-Received: by rv-out-0708.google.com with SMTP id k29so2214319rvb.6 for ; Sat, 15 Nov 2008 16:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=45qJG2Oy7B+0FdUoarEk6nilLzmy/eL4txE1SXCqKvo=; b=RxUIVtSrAjogdV8Je6n1feAsvvXFbASKCFWnO/kBcjK7eUySzh5BMiKQvoK/QJWbmX I9Y36kwvMJ8IoEaLj2HMZkSGcGCtjJoRGsVq9uguHRhFUu2ZIzEHlvsx62c+GOLhBeKi R5NCzQG6Rxd0QihWRkJQF3uuQ/kO4Soqv67qE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=G1A08UnKBCH5UrFA1NHhrEgxLgTsUSBvSdXnDA3OlakiXrtlzXU9YS8Abn8rvkonuL MQq1qIFyrYUECfSjuhccLNFQWbdOnceo5J4EKbhwE6ek9ZX52LCho0t5U73hKCqjvwRQ jS2+EE42y7opyeEWhYIXFmxAT4dF6R6a5vIVg= Original-Received: by 10.141.162.1 with SMTP id p1mr1385569rvo.293.1226793785757; Sat, 15 Nov 2008 16:03:05 -0800 (PST) Original-Received: by 10.140.142.15 with HTTP; Sat, 15 Nov 2008 16:03:05 -0800 (PST) In-Reply-To: <87prl2m2du.fsf@gnu.org> Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6921 gmane.lisp.guile.devel:7847 Archived-At: 2008/11/11 Ludovic Court=E8s : > > Your note doesn't take binary compatibility into account, and I think > it's an important thing, too. I think the ideal is to maintain binary > compatibility within a major series, as we've done (or tried to do) in > the 1.8.x series. (And Andy wrote "I think it needs to be guaranteed.") But this isn't obvious to me. _If_ the libtool versioning system works in practice, in the senses of - permitting linking when it ought to be permitted - failing linking when it ought to fail - providing a clear error message in the failure cases, so that the user knows what to do next then it seems to me that a reasonable division of labour is for us (upstream) to take care of API compatibility, and ensuring that the libtool numbers are a correct description of ABI state, and for distributions/users to take care of any consequences of mismatched libtool numbers. I think the latter "consequences" are just having to recompile something against the new libguile version. For a user who has already decided to use the source code version of an application, that should be trivial; for distributions, that's just what they do all the time, isn't it? Are there other consequences that I'm missing? Sure, we could also take on ABI compatibility ourselves, but I think that overconstrains our development, and/or makes it harder. > This is very convenient for binary distributions like > Debian, and for users in general. Are you sure about that? I would expect Debian already to have completely automatic ways of coping with this kind of thing (i.e. libtool numbers changing). And I've described what I think the impact on users is above; seems quite small to me. > I think enhancements like the lazy symbol binding in modules > could have been in theory added in 1.8.x since it breaks neither the API > nor the ABI. Agreed; and I think they still can be added in 1.8.x. > Things like `libguile-i18n' could have been added too, but > the issue when adding C code is portability: it may be that this module > would have caused build issues on some platforms. Now, with more > frequent releases, it would be reasonable to hope that such regressions > would quickly be fixed. Agreed, I think we can handle this. > Another thing is actual big jumps. I think the addition of the VM is a > big jump. Yes, but it's an addition. As far as I understand, it's completely back-compatible, so I would be perfectly happy to feed this in to 1.8.x at some point. Of course, we should take care that we are 99% happy with the new APIs before releasing them, as it wouldn't be good to make lots of changes later. But that's no different from the first public release of anything - in my view, it should work much better for us to come to this determination feature-by-feature, than to say arbitrarily at some point "everything in master" is now ready. > A GC change, or a rewrite of the string/char code with > Unicode support would be a big jump, too. Such big jumps surely need a > new major release. Not necessarily, in my view. We have an extensive test suite, and I think we can have some confidence in that. After sufficient testing, I would see no problem with your proposed BDW-GC changes going into a 1.8.x release. Same for Unicode support - if the API stayed compatible. If the API could not be compatible, then I would agree that we might need a new major release. > BTW, we need to consider releasing 1.8.6 one of these days! ;-) Yes. Do we have any particular more things to get into this? (I don't think I have anything.) Neil