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: Tue, 09 Dec 2008 18:01:08 +0100 Message-ID: <871vwh9tbf.fsf@gnu.org> References: <49dd78620811101723m6b014589ua01037d5ea3f17b9@mail.gmail.com> <3ae3aa420811101944m23d7a72ch992c253326f7e236@mail.gmail.com> <49dd78620811151516l2f59808co2af6d1f38cd3db9c@mail.gmail.com> <873ahrl00d.fsf@gnu.org> <87d4gtl4fc.fsf@gnu.org> <49dd78620812081405r4e1e4d21sf9b45ca5a4935d58@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 1228842547 14174 80.91.229.12 (9 Dec 2008 17:09:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2008 17:09:07 +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 Tue Dec 09 18:10:10 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 1LA65K-00006o-5M for guile-user@m.gmane.org; Tue, 09 Dec 2008 18:09:22 +0100 Original-Received: from localhost ([127.0.0.1]:36237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LA649-0005Tz-1i for guile-user@m.gmane.org; Tue, 09 Dec 2008 12:08:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LA5xh-0001dS-CZ for guile-user@gnu.org; Tue, 09 Dec 2008 12:01:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LA5xf-0001ca-6Z for guile-user@gnu.org; Tue, 09 Dec 2008 12:01:27 -0500 Original-Received: from [199.232.76.173] (port=60407 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LA5xd-0001cP-Th for guile-user@gnu.org; Tue, 09 Dec 2008 12:01:26 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:34057 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 1LA5xd-00013Q-7J for guile-user@gnu.org; Tue, 09 Dec 2008 12:01:25 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LA5xb-0006IT-Qw for guile-user@gnu.org; Tue, 09 Dec 2008 17:01:23 +0000 Original-Received: from 193.50.110.227 ([193.50.110.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Dec 2008 17:01:23 +0000 Original-Received: from ludo by 193.50.110.227 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Dec 2008 17:01:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Followup-To: gmane.lisp.guile.devel Original-Lines: 34 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 193.50.110.227 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 19 Frimaire 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:D9PgCvhZ1hCu/B7Av05X73XOPuc= 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:6993 gmane.lisp.guile.devel:7909 Archived-At: Hi Neil! "Neil Jerram" writes: > OK, it's clear the consensus on 1.8.x is against my suggestion, so > I'll accept that. And I can understand the reasons too. I think > perhaps it comes down to Ludovic's point about the version number > being a hint - i.e. people already have expectations about what should > be in the change from 1.8.x to 1.8.x+1, and mostly those expectations > seem to be API and ABI compatibility, so it makes sense to comply with > that. Yep, it's just a matter of labeling, really. > For 1.10.0, then, we just need to check that there isn't anything in > master that isn't ready/working; if there is, it should be moved into > a branch. In a similar vein, some of the things developed in the 1.7 series, like futures, were never stabilized and are simply commented out for now. Thread support is also somewhat sloppy, as shown my recent reports (e.g., parallel memoization). We need to think about these as well. > And from here on we should adopt the rule that new features > are always developed on branches, and only merged into master when > ready and working. Then we should be able to release master as a new > 1.y+2.0 whenever we see that enough new features have accumulated. > > How does that sound? Sounds good to me! Thanks, Ludo'.