From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Guile release planning Date: Mon, 8 Dec 2008 22:05:34 +0000 Message-ID: <49dd78620812081405r4e1e4d21sf9b45ca5a4935d58@mail.gmail.com> References: <49dd78620811101723m6b014589ua01037d5ea3f17b9@mail.gmail.com> <3ae3aa420811101944m23d7a72ch992c253326f7e236@mail.gmail.com> <49dd78620811151516l2f59808co2af6d1f38cd3db9c@mail.gmail.com> <873ahrl00d.fsf@gnu.org> <87d4gtl4fc.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1228773964 16637 80.91.229.12 (8 Dec 2008 22:06:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2008 22:06:04 +0000 (UTC) Cc: guile-user@gnu.org, guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Dec 08 23:07:07 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 1L9oFk-00084W-5G for guile-user@m.gmane.org; Mon, 08 Dec 2008 23:06:56 +0100 Original-Received: from localhost ([127.0.0.1]:50109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9oEZ-0002rt-7U for guile-user@m.gmane.org; Mon, 08 Dec 2008 17:05:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L9oEV-0002rS-17 for guile-user@gnu.org; Mon, 08 Dec 2008 17:05:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L9oEU-0002r8-FF for guile-user@gnu.org; Mon, 08 Dec 2008 17:05:38 -0500 Original-Received: from [199.232.76.173] (port=56194 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9oEU-0002r5-5g for guile-user@gnu.org; Mon, 08 Dec 2008 17:05:38 -0500 Original-Received: from fg-out-1718.google.com ([72.14.220.153]:5746) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L9oET-0005SF-A8 for guile-user@gnu.org; Mon, 08 Dec 2008 17:05:37 -0500 Original-Received: by fg-out-1718.google.com with SMTP id l26so1004091fgb.30 for ; Mon, 08 Dec 2008 14:05:35 -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=9SzJx6yUCFQde1NqPcEtlDsgI3GmHIwwVOXfso8e/qk=; b=SKg89fNW7DecpYCPY1ZGy5VJwmIGd9CDd+t1Rk507Zt17zP/BycX/W/tD8jAY1aBSD 0YKK381qEtXDaF2g+iamyBPALi8Z3NeL9ua/GTo1W2VYf/EbxI7DJTnTcCdc3lV6cdJn wx9riKXjZnyCm0ZWoGAAs+mAvLvSmCLmCZnVM= 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=xPvcwvFQJhXLHf2vt3EwFU3A00tFq4AoC4cmx6w6Mr5X3xcdqbbgzcZfd5eLxgM64f MT07rjf9TEP2AZQgCisTnrnLyUblSy5pXyODAT79wgdn9qMKpaxFzvkbI38xRBkD0827 TCboP3N9GaMOJz4/pep8RSkIZ9+LMASt57wD8= Original-Received: by 10.181.61.18 with SMTP id o18mr1382453bkk.78.1228773934937; Mon, 08 Dec 2008 14:05:34 -0800 (PST) Original-Received: by 10.181.59.9 with HTTP; Mon, 8 Dec 2008 14:05:34 -0800 (PST) In-Reply-To: <87d4gtl4fc.fsf@gnu.org> Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:6992 gmane.lisp.guile.devel:7907 Archived-At: 2008/11/18 Ludovic Court=E8s : > Hi, > > Andy Wingo writes: > >> Beating a dead horse, 1.8.5 should be compatible with 1.8.3, via >> whatever mechanism. (The actual problem in this case was elsewhere.) > > 1.8.5 *is* compatible with 1.8.x. > >> I am skeptical of pushing significant changes into stable branches. I >> really don't want to be in the situation in which 1.8.4 works for >> someone, but 1.8.7 does not. You might be right, Neil, about that path, >> but it does not give me warm fuzzy feelings. > > Same for me, but we can surely find a reasonable trade-off. Many thanks everyone for your replies to this thread, and sorry for my delay in following up. 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. One of my background concerns, when suggesting that we try to get more into 1.8.x, was that if we have lots of release branches (e.g. 1.6.x, 1.8.x and 1.10.x) in use at the same time, we have to do more work to apply fixes to all branches. But in fact that is a lot easier now that we use Git, so probably isn't a big worry. For new features, then, the question becomes: what is our general plan, from here on, for going from 1.y.x to 1.y+2.0 ? As Greg has said, we need to get new stuff out quicker than we have done in the past. Right now we have an growing pile of new stuff in Git, should _all_ of that go into 1.10? I guess the answer is that 1.10.0 - and more generally any new 1.y+2.0 - should include everything that we have which - we believe is ready, i.e. in a sufficiently final form that its API/ABI is unlikely to be broken in future - is working. 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. 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? Neil