From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Guile release planning Date: Mon, 17 Nov 2008 00:55:50 +0100 Message-ID: <87ljvjcjjt.fsf@gnu.org> References: <49dd78620811101723m6b014589ua01037d5ea3f17b9@mail.gmail.com> <87prl2m2du.fsf@gnu.org> <49dd78620811151603t67745c6fy7eb8b5134f883521@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1226879781 2706 80.91.229.12 (16 Nov 2008 23:56:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2008 23:56:21 +0000 (UTC) Cc: guile-devel@gnu.org To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Nov 17 00:57:22 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 1L1rUY-0008Dj-0n for guile-user@m.gmane.org; Mon, 17 Nov 2008 00:57:22 +0100 Original-Received: from localhost ([127.0.0.1]:52530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1rTP-0007y7-Du for guile-user@m.gmane.org; Sun, 16 Nov 2008 18:56:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1rTM-0007y1-5t for guile-user@gnu.org; Sun, 16 Nov 2008 18:56:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1rTK-0007xp-Cl for guile-user@gnu.org; Sun, 16 Nov 2008 18:56:06 -0500 Original-Received: from [199.232.76.173] (port=33914 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1rTK-0007xm-5j for guile-user@gnu.org; Sun, 16 Nov 2008 18:56:06 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:39198 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L1rTJ-00068f-Ff for guile-user@gnu.org; Sun, 16 Nov 2008 18:56:05 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L1rTF-0005mv-1b for guile-user@gnu.org; Sun, 16 Nov 2008 23:56:01 +0000 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2008 23:56:01 +0000 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2008 23:56:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Followup-To: gmane.lisp.guile.devel Original-Lines: 99 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 27 Brumaire an 217 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Cancel-Lock: sha1:Pvu5+OPeAlgE15pgxtf3TOiCJQI= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:6928 gmane.lisp.guile.devel:7853 Archived-At: Hello! "Neil Jerram" writes: > 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 It partly fails for the second point. Examples: changing the number/type of arguments of a function, changing the layout of a public structure, changing the implementation of public macros, etc. It really requires special care to check whether a change is breaking ABI compatibility. > 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 consider ABI compatibility as important, too, because people don't want to recompile everything every time a minor release is out. Like Andy said, we should guarantee it within a given series, e.g., 1.8.x. After all, the version number is just a label giving users a hint about the type of changes introduced in a version and level of compatibility provided. It's common for free software libraries to remain ABI-compatible within a major series (first and second digits unchanged), to change to the second digit when ABI breaks, and possibly the first digit when API breaks *or* important changes are introduced. >> This is very convenient for binary distributions like >> Debian, and for users in general. > > Are you sure about that? Yes. Even for the few Guile C libraries I develop myself, it's boring to recompile them when switching from 1.8 to 1.9 or one of the other branches. For a distribution, it means burning a lot of CPU power. >> 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. Yes, but one con could be that it introduces changes that could be visible to users that access Guile's undocumented module-fiddling API. > 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. >From a marketing viewpoint, the VM deserves a new version number. :-) In practice, it also requires users to adapt their build system to take advantage of it. > 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. I agree that a feature-by-feature approach would be more reasonable. My impression, gathered since the time when Kevin was still with us, was that the goal was zero-breakage within a stable series, such that 1.8.x+1 would always be more portable and reliable that 1.8.x. This approach rules out things like the lazy duplicate symbol resolution, and `libguile-i18n'. Surely we could find an "in-between". > 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. The BDW-GC change is ABI-incompatible, it introduces a new dependency, augments the API and potentially introduces subtle changes in behavior, so I would definitely change the version number for that. Again, that version number is just a hint for users. >> 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.) I'm interested in the scm_c_read issue I raised on the list, and Linas is interested in threading issues. The former seems more important to me (eh eh ;-)) because it introduces a regression. Then, I don't think we have to solve every single bug right now, it's already been too long since 1.8.5. Thanks, Ludo'.