Re: Guile release planning

[Ludovic Courtès]

Hello!

Andy Wingo <address@hidden> writes:

> I think we went wrong in the 1.4->1.6 and 1.6->1.8 transitions, by
> leaving /source files/ to bitrot. We should have provided
> guile-1.6-compat.[ch] and guile-1.8-compat.[ch] files for users to
> include in their source trees, wrapping e.g. the gh_* API, or SCM_INUM.
> That way their code stays usable, ours stays maintainable, and whenever
> they decide to port to the new API, they already know how -- it's in
> their source tree.

Hmm, we have `gh.c' and `deprecated.c', which are kind enough to (i)
provide compatibility wrappers, and (ii) tell users how to upgrade to
the new API.  What do you dislike about it?

Or maybe you're referring to things like `guile-compatibility.h' in
G-Wrap?  Basically, it allows G-Wrap to use the latest API and have it
work with the older versions of Guile.

> Finally, a bit of marketing: in my opinion, the next Guile should be
> 2.0. The meaning ABI/API-wise is the same as 1.10, but it can have a
> very nice impact on people's perceptions.

I concur.  :-)

Thanks,
Ludo'.