[Top][All Lists]

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

Re: Guile release planning

From: Neil Jerram
Subject: Re: Guile release planning
Date: Sat, 15 Nov 2008 23:03:53 +0000

Hi Mike, thanks for your response.

2008/11/11 Mike Gran <address@hidden>:
> If the base Guile C API remains stable, it doesn't matter to me how the 
> releases occur, because they won't break my libraries or projects.


> If the Guile C API needs to change, some sort of notification and beta 
> pre-release would be preferred, so that I can test my projects before the new 
> Guile gets yum'ed out to my group.

How exactly would a "beta pre-release" help?  It seems you have in
mind people who are building your project from source, using a
distro-updated libguile.  Even with notification/pre-release, and with
you having updated your code accordingly, one of your users might not
have downloaded your updated code.

I guess I can see, though, that it's nice if you have a bit of notice,
and hence time to prepare an update.  And then I can also see that to
do that you will want real code to work with, not just an English
description of the API change.

I would propose, then, that we clearly flag (on the mailing list) an
API change at the time when the relevant commit is made to the
repository, and make sure that some minimum period of time elapses
before the subsequent release.  I would hope that you could then work
on the basis of the commit, without needing a formal pre-release.
(Any kind of release takes a bit of time, and pre-releases might
confuse the overall release picture.)

Would that work?


reply via email to

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