From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jon Wilson Newsgroups: gmane.lisp.guile.user Subject: Re: Guile release planning Date: Mon, 10 Nov 2008 22:18:00 -0500 Message-ID: <4918F968.2090205@wilsonjc.us> References: <49dd78620811101723m6b014589ua01037d5ea3f17b9@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT X-Trace: ger.gmane.org 1226374974 31232 80.91.229.12 (11 Nov 2008 03:42:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2008 03:42:54 +0000 (UTC) To: guile-user Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Nov 11 04:43:55 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 1KzkAU-0000fX-Oy for guile-user@m.gmane.org; Tue, 11 Nov 2008 04:43:55 +0100 Original-Received: from localhost ([127.0.0.1]:54290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kzk9K-0003Xn-US for guile-user@m.gmane.org; Mon, 10 Nov 2008 22:42:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kzk97-0003Xh-OC for guile-user@gnu.org; Mon, 10 Nov 2008 22:42:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kzk95-0003XV-Nj for guile-user@gnu.org; Mon, 10 Nov 2008 22:42:28 -0500 Original-Received: from [199.232.76.173] (port=44830 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kzk95-0003XS-K4 for guile-user@gnu.org; Mon, 10 Nov 2008 22:42:27 -0500 Original-Received: from mailgw1.fnal.gov ([131.225.111.11]:53252) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kzk95-0003mB-2l for guile-user@gnu.org; Mon, 10 Nov 2008 22:42:27 -0500 Original-Received: from mailav1.fnal.gov (mailav1.fnal.gov [131.225.111.18]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KA5009K1FSV7L@mailgw1.fnal.gov> for guile-user@gnu.org; Mon, 10 Nov 2008 21:18:02 -0600 (CST) Original-Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav1.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2008111021180117421 for ; Mon, 10 Nov 2008 21:18:01 -0600 Original-Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KA500F01FTDW5@mailgw1.fnal.gov> (original mail from jsw@wilsonjc.us) for guile-user@gnu.org; Mon, 10 Nov 2008 21:18:02 -0600 (CST) Original-Received: from wilsonjc.us (cpe-75-187-46-126.columbus.res.rr.com [75.187.46.126]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTPSA id <0KA5009HCFU15P@mailgw1.fnal.gov> for guile-user@gnu.org; Mon, 10 Nov 2008 21:18:01 -0600 (CST) In-reply-to: <49dd78620811101723m6b014589ua01037d5ea3f17b9@mail.gmail.com> User-Agent: Thunderbird 2.0.0.17 (X11/20080925) X-detected-operating-system: by monty-python.gnu.org: Solaris 9 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:6866 Archived-At: Hi Neil, Thanks for working on this. I'd favor the steady new features model, but I would recommend periodically marking a release as one that will be supported past the next release, similar to Ubuntu's LTS releases. Regards, Jon Neil Jerram wrote: > Andy recently wondered - in connection with his VM implementation and > docs - about when a 1.9.x or 1.10.x release might happen, and that > reminded me about the following thoughts that I've been trying to > crystallize for a while. How should we organize future Guile > releases? I'm interested to hear both developer and user views on > this, hence the cross-posting. > > In my view, the most important thing for Guile's near-to-medium-term > future is focus. By that I mean having developers working on, and > users using, as far as possible, a similar level of code. In the > past, we did big jumps - from 1.4.x to 1.6.x, and from 1.6.x to 1.8.x > - which I think left users unable easily to upgrade, or perhaps just > unsure of whether to upgrade. From the developer point of view, they > increased the support burden (because of some users staying with the > old series). Also the big jump model can be frustrating for > developers, because it tends to mean that there is a long time between > when a shiny new feature is ready, and when it gets released and so > into the hands of most users. > > Those past jumps were probably justified, but I'm not sure they are in > future. I wonder if a better model would be to have a single ongoing > series of releases, and to feed new features one by one into that. In > principle the jump from one release to the next would always be small, > and so should allow everyone to upgrade easily. I think this will > allow the community to stay closer together (in code terms), and will > allow developers to get interesting new features out into the wild > more quickly. > > I also think it will help us manage API incompatibilities better. I > think our default position from now on should be to maintain > source-level (API) compatibility, but it is inevitable that there will > be exceptions to this. When we did a big jump in the past, we did > document all the API changes, but perhaps not as well as could have > been done. If, in future, each individual release contains less API > change, I think we can do a better job of fully describing that, and > how to cope with it. > > So, what do you think? There have been discussions of release > strategy in the past, which I've seen as 50/50 between the split > stable and development model (which we have now) and the steady new > feature model (described above), but I don't recall them considering > the overall community focus angle before. In my view, when we add in > that angle, the steady new feature model is better. > > Regards, > Neil > >