From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Guile release planning Date: Sat, 15 Nov 2008 23:16:04 +0000 Message-ID: <49dd78620811151516l2f59808co2af6d1f38cd3db9c@mail.gmail.com> References: <49dd78620811101723m6b014589ua01037d5ea3f17b9@mail.gmail.com> <3ae3aa420811101944m23d7a72ch992c253326f7e236@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1226790986 11903 80.91.229.12 (15 Nov 2008 23:16:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2008 23:16:26 +0000 (UTC) Cc: guile-user , guile-devel To: linasvepstas@gmail.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Nov 16 00:17:29 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L1UOG-00008B-U9 for guile-devel@m.gmane.org; Sun, 16 Nov 2008 00:17:21 +0100 Original-Received: from localhost ([127.0.0.1]:43718 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1UN8-0000eQ-9D for guile-devel@m.gmane.org; Sat, 15 Nov 2008 18:16:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1UN5-0000dx-0Q for guile-devel@gnu.org; Sat, 15 Nov 2008 18:16:07 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1UN4-0000df-HW for guile-devel@gnu.org; Sat, 15 Nov 2008 18:16:06 -0500 Original-Received: from [199.232.76.173] (port=48835 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1UN4-0000da-Ch for guile-devel@gnu.org; Sat, 15 Nov 2008 18:16:06 -0500 Original-Received: from rv-out-0708.google.com ([209.85.198.250]:36906) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L1UN4-0000Su-3H for guile-devel@gnu.org; Sat, 15 Nov 2008 18:16:06 -0500 Original-Received: by rv-out-0708.google.com with SMTP id k29so2203574rvb.6 for ; Sat, 15 Nov 2008 15:16:04 -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=+jVuvjD1JG6DLaDJ0UKY7Pxwwt94hijyuuzdsAcfPb8=; b=YsjJEj/4wl/euMjhkozoaSSIcw2a0GhcHz4/zeY5vreKipDJTKi73HwZ/DpuTENscm 5QyQmie+3eRULfVlpIh27Lgh1hgxJKk7GsEg+VR5kTc0C8uVMg7uDnecmXDrFjE6yQic Etr1V7ocspcs1wgLvF7vEFShrhJLzoBEOuW+g= 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=o//abkVLQq6OBkNTBXsueZjBGhbvxEVPnSNQWXWXxx51YxljiT0b4xw/eS4yE5+HKm bS1CljnDV7M9w23ljLqVrW1yRq/0dLWpvhxGs/wqm87Z0mbdCqj03TIjvpvXQeTY6S/X qOtQW8cbFF7lqzngc6Jv4wJCCZ98lSIHCxQmg= Original-Received: by 10.140.192.9 with SMTP id p9mr1387023rvf.57.1226790964768; Sat, 15 Nov 2008 15:16:04 -0800 (PST) Original-Received: by 10.140.142.15 with HTTP; Sat, 15 Nov 2008 15:16:04 -0800 (PST) In-Reply-To: <3ae3aa420811101944m23d7a72ch992c253326f7e236@mail.gmail.com> Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7845 gmane.lisp.guile.user:6918 Archived-At: 2008/11/11 Linas Vepstas : > > Any ideas for binary compatibility for the "micro" revisions? At our "upstream" level (i.e. not trying to solve all of the distribution-level issues), I think the theory is that this is covered by library interface numbering. In other words, if a change in guile causes the new libguile not to be compatible with the previous one, libguile's revision number should be incremented. > I recently discovered that a library compiled against 1.8.3 > would core dump when used with an application compiled > against 1.8.5. And I assume the actually loaded libguile was version 1.8.5? So there should have been something in the library saying that it needed 1.8.3, which would have caused the link to fail. Does the libtool scheme cover this; I'm afraid I just don't know. > The linux kernel got rid of the stable/unstable branch idea, > and it's worked really really well. (the reasons why are > widely documented) I'm for it. Yes, I guess my suggestion is quite similar to what the kernel did. Thanks, Neil