Guile release planning

[Neil Jerram]

Andy recently wondered - in connection with his VM implementation and
docs - about when a 1.9.x or 1.10.x release might happen, and that
reminded me about the following thoughts that I've been trying to
crystallize for a while.  How should we organize future Guile
releases?  I'm interested to hear both developer and user views on
this, hence the cross-posting.

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.

Those past jumps were probably justified, but I'm not sure they are in
future.  I wonder if a better model would be to have a single ongoing
series of releases, and to feed new features one by one into that.  In
principle the jump from one release to the next would always be small,
and so should allow everyone to upgrade easily.  I think this will
allow the community to stay closer together (in code terms), and will
allow developers to get interesting new features out into the wild
more quickly.

I also think it will help us manage API incompatibilities better.  I
think our default position from now on should be to maintain
source-level (API) compatibility, but it is inevitable that there will
be exceptions to this.  When we did a big jump in the past, we did
document all the API changes, but perhaps not as well as could have
been done.  If, in future, each individual release contains less API
change, I think we can do a better job of fully describing that, and
how to cope with it.

So, what do you think?  There have been discussions of release
strategy in the past, which I've seen as 50/50 between the split
stable and development model (which we have now) and the steady new
feature model (described above), but I don't recall them considering
the overall community focus angle before.  In my view, when we add in
that angle, the steady new feature model is better.

Regards,
        Neil