Re: Guile release planning

[Andy Wingo]

Howdy Neil,

Great post!

On Tue 11 Nov 2008 02:23, "Neil Jerram" <address@hidden> writes:

> How should we organize future Guile releases?
>
> 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).

So, my history with Guile does not go back to the 1.4 days, but let's
take the data point that I think there are people out there doing
conditional compilation against 1.4 *and* 1.6 *and* 1.8.

What this says to me is that there is a class of users that was
satisfied with the facilities that 1.4 offered them, and has been
reluctantly adding #ifdefs ever since.

Then, you have users interested in new versions: those who want to use
pthreads, who want internationalization, who perceive benefit in API
cleanups -- in short, those with stockholm syndrome ;-)

Then you have the Manly Men Schemers, and it is a testosterone-laden
group for some reason. (I am pleased that this does not describe most
Guilers.) These are those that judge an implementation against other
implementations of a Scheme standard, together with the extensions
provided, and who snub their noses at Copying Call/CC and Conservative
Collection. But some of them deign to use Guile, usually for its
portability, Ubiquity (hah!), and the extensions that it provides.


The question is, what does change do to these groups of users?

To the first it is a burden. Continuity is key, certainly on the source
level, and to a lesser extent on the binary level. They can recompile
their software but they don't want to spend time adjusting to API
cleanups in Guile. That's cool.

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.

So in the future, as we make API breaks, we should provide these people
with breadcrumbs in the form of compatibility shims, and think of the
body of source code that is out there as we make our changes.


Then for the second kind of user, well, our job is to be Consistent: to
have powerful, orthogonal, and well-documented APIs, so that they can
get their work done. I think that we serve these people well, and that
over time we serve them better and better, with occaisional regressions
(e.g. the COW string stuff in the leadup to 1.8).


For the third group... they have been leaving us, because other Schemes
are getting faster and more capable over time. But here we have some
secret weapons: the wonderful Emacs integration, the VM, the possibility
for JIT compilation, possiblity for R6 integration as well -- not to
mention the broad range of extensions that Guile still has. So here our
job is to extend the boundaries of Guile as a Scheme, to make it a
system that you want to inhabit and write *all* of your program, and all
of your programs, in.


(Did you like the dangling preposition?)


So for me, and I'm babbling I know, the things are:

 * Shims for those that don't have time to deal with changes
   - will get people off of guile 1.6
 * Quicker binary-compatible development cycles for all
   - we should be up to 1.8.20 by now ;)
   - limited by developer resources of course, though now we are doing
     well
 * Break when you have something new to offer the second or third group
   - it's about time :)


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. It's like the presentation at
the recent GUADEC:

   GNOME 2.30

   => GNOME 30

   => GNOME 3.0

   Guile 1.10

   = > Guile 2.0

Imperfect, but delightful, no?

Happy hack,

Andy
-- 
http://wingolog.org/