SL Baur <steve(a)xemacs.org&gt; writes: My sentiments exactly. One way to think of the binary-kits is as a "go-ahead" from us to the user-base to switch to a particular release. Building good binary-kits takes time and patience and I think they should be made available only for rock-solid releases (such as 20.4). For releases in between there is always the source code for the more experienced users. For example, in between 21.0 and 21.1 we will have the chance to see how most people actually use the package system which will allow us to choose a better default for the binary-kits. I anticipate a full line of binary-kits for 21.1. Yes, I'd also like to work out a new methodology for binary-kits in the face of more frequent releases. I was bitten by the Mule bug at m17n99, so I'd like to continue the recent tradition of providing both Mule and non-Mule binary-kits for each platform. I'm also thinking of experimenting with a more automated method of building the binary-kits[1]. The current method of distributing a long, detailed README for builders to follow is too error prone. I end up having to hand-fix or reject many of the submissions because of omissions or mistakes. Anyway, I think this process could be improved. Please feel free to share your suggestions on these issues with myself or the list. Footnotes: 1. Such as how Apache does it: <http://dev.apache.org/binaries.html>