[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Guile 2.1.7 released (beta)

From: Andy Wingo
Subject: Re: GNU Guile 2.1.7 released (beta)
Date: Thu, 23 Feb 2017 19:54:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

On Sat 18 Feb 2017 11:31, Andy Wingo <address@hidden> writes:

> At this point you might ask yourself when 2.2.0 is coming.  The answer
> is, very soon!  A followup mail will propose a timeline and a list of
> blocker bugs.  I would like to aim for final prerelease in another 4
> weeks and a final release a week after that.

Ahem :)

I think that the 2.1.x series is ready to go.  There are bugs which we
should fix of course.  Some of those bugs can be fixed within the stable
series; some we can't.  Of the bugs that we can't, some we can punt to
the next stable series, but some are _release blockers_ -- bugs that we
need to fix before 2.2.0.

Release blocker bugs principally concern ABI.  For example the foreign
objects facility which was applied to 2.0 and 2.2 and then rolled out
from 2.0 because maybe it's not an interface that we want to support in
the future -- well that is still part of 2.2 and if we released today we
would indeed have to support it.  It's that kind of question.

So!  Release blockers.

 * Foreign objects.  In or out?  Let's start a subthread.

 * The approach to macro-introduced top-level identifiers: OK or no?
   Again a subthread would be the thing.

 * GOOPS: are there incompatible changes that we think are bad?
   Subthread :)

There are a number of other bugs that are also important
(reproducibility, broken REPL server) that aren't strictly blockers in
the sense that we can release a 2.2.x that fixes them.  Those are
interesting but unless you want to schedule _your_ work/resources to get
them done, they are not blockers, as far as I undersand things.

I propose to release a 2.1.8 on 9 March.  At that point I would like to
have all release blockers resolved one way or the other.  Then we can
release a 2.2.0 whenever, provided that 2.1.8 release actually compiles




reply via email to

[Prev in Thread] Current Thread [Next in Thread]