In principle, it seems to me that we should make a new stable release whenever - and as soon as - we make a fix in one of the stable branches. In practice, we might want to temper that a little, by (a) leaving a short while - say 2-3 days - after committing a fix, just in case of a glaring mistake that would be picked up by another developer building (b) postponing a release following one fix if we know that some other fixes will be available every soon - to avoid stupidly frequent releases. Right now we have stable releases at intervals best measured in years (0 in 2005, 3 in 2006). While having them more often would be good, 2-3 days is way too ambitious. I'd suggest as something that is achievable and would be useful: release 2 months after last release if anything significant has changed (where significant means new feature or bug fix) release 6 months after last release if anything has changed at all release after a 1 week cooling off period if a serious bug is fixed While newer stable releases are a good thing, having 24 a year isn't. packaging systems won't keep up, and then won't know which to package. For pkgsrc, it's really easy to update if there aren't changes to build procedure or new/deleted files. In my view, the main path to guile usage by other than the people on this list is via stale releases and then packaging systems. This enables other people to choose to depend on guile. Currently, that's a scary choice to make. -- Greg Troxel