From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: Stable releases Date: Tue, 21 Nov 2006 07:06:42 -0500 Message-ID: References: <87bqn5n48n.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1250699472==" X-Trace: sea.gmane.org 1164110817 26364 80.91.229.2 (21 Nov 2006 12:06:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2006 12:06:57 +0000 (UTC) Cc: Guile Development Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Nov 21 13:06:54 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GmUOp-0002sz-8r for guile-devel@m.gmane.org; Tue, 21 Nov 2006 13:06:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GmUOo-0007Ks-Ou for guile-devel@m.gmane.org; Tue, 21 Nov 2006 07:06:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GmUOl-0007JM-Pe for guile-devel@gnu.org; Tue, 21 Nov 2006 07:06:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GmUOk-0007J1-Cg for guile-devel@gnu.org; Tue, 21 Nov 2006 07:06:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GmUOk-0007Iy-6l for guile-devel@gnu.org; Tue, 21 Nov 2006 07:06:46 -0500 Original-Received: from [192.1.100.210] (helo=fnord.ir.bbn.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GmUOj-0000z3-OV for guile-devel@gnu.org; Tue, 21 Nov 2006 07:06:45 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 786AD5289; Tue, 21 Nov 2006 07:06:45 -0500 (EST) Original-To: Neil Jerram In-Reply-To: <87bqn5n48n.fsf@ossau.uklinux.net> (Neil Jerram's message of "Fri\, 17 Nov 2006 21\:38\:16 +0000") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix) X-Hashcash: 1:20:061121:neil@ossau.uklinux.net::tyAaKJYXe8VG4c9O:0000000000000000000000000000000000000000Ry9 X-Hashcash: 1:20:061121:guile-devel@gnu.org::MRM3RSc848bupJZL:000000000000000000000000000000000000000000BsNX 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:6228 Archived-At: --===============1250699472== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable In principle, it seems to me that we should make a new stable release whenever - and as soon as - we make a fix in one of the stable branches. In practice, we might want to temper that a little, by (a) leaving a short while - say 2-3 days - after committing a fix, just in case of a glaring mistake that would be picked up by another developer building (b) postponing a release following one fix if we know that some other fixes will be available every soon - to avoid stupidly frequent releases. Right now we have stable releases at intervals best measured in years (0 in 2005, 3 in 2006). While having them more often would be good, 2-3 days is way too ambitious. I'd suggest as something that is achievable and would be useful: release 2 months after last release if anything significant has changed (where significant means new feature or bug fix) release 6 months after last release if anything has changed at all release after a 1 week cooling off period if a serious bug is fixed While newer stable releases are a good thing, having 24 a year isn't. packaging systems won't keep up, and then won't know which to package. For pkgsrc, it's really easy to update if there aren't changes to build procedure or new/deleted files. In my view, the main path to guile usage by other than the people on this list is via stale releases and then packaging systems. This enables other people to choose to depend on guile. Currently, that's a scary choice to make. =2D-=20 Greg Troxel --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (NetBSD) iD8DBQFFYuvV+vesoDJhHiURAsG+AJ4p1ePGKsMUaCuWGvHqZaS2Ck3JpwCgk2j5 xh7g6YiQkm8mflObc0tYCpQ= =BNML -----END PGP SIGNATURE----- --=-=-=-- --===============1250699472== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel --===============1250699472==--