Re: Guile release planning

[ludo@gnu.org (Ludovic Courtès)]

Hello!

"Neil Jerram" <neiljerram@googlemail.com> writes:

> In my view, the most important thing for Guile's near-to-medium-term
> future is focus.  By that I mean having developers working on, and
> users using, as far as possible, a similar level of code.  In the
> past, we did big jumps - from 1.4.x to 1.6.x, and from 1.6.x to 1.8.x
> - which I think left users unable easily to upgrade, or perhaps just
> unsure of whether to upgrade.  From the developer point of view, they
> increased the support burden (because of some users staying with the
> old series).  Also the big jump model can be frustrating for
> developers, because it tends to mean that there is a long time between
> when a shiny new feature is ready, and when it gets released and so
> into the hands of most users.

I fully agree with this, but...

Your note doesn't take binary compatibility into account, and I think
it's an important thing, too.  I think the ideal is to maintain binary
compatibility within a major series, as we've done (or tried to do) in
the 1.8.x series.  This is very convenient for binary distributions like
Debian, and for users in general.  Thus, introducing ABI
incompatibilities should imply increasing the first or second digit of
the version number, IMO.

Maintaining ABI compatibility doesn't mean we can't add new features,
though.  In the course of the 1.8.x series, several Scheme modules were
added.  I think enhancements like the lazy symbol binding in modules
could have been in theory added in 1.8.x since it breaks neither the API
nor the ABI.  Things like `libguile-i18n' could have been added too, but
the issue when adding C code is portability: it may be that this module
would have caused build issues on some platforms.  Now, with more
frequent releases, it would be reasonable to hope that such regressions
would quickly be fixed.

Another thing is actual big jumps.  I think the addition of the VM is a
big jump.  A GC change, or a rewrite of the string/char code with
Unicode support would be a big jump, too.  Such big jumps surely need a
new major release.

BTW, we need to consider releasing 1.8.6 one of these days!  ;-)

Thanks!

Ludo'.