Hi Mike, thanks for your response.
2008/11/11 Mike Gran <[EMAIL PROTECTED]>:
> 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.
OK.
> 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?
Neil
