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