XEmacs 21.0 binary-kits
SL Baur <steve(a)xemacs.org> writes:
> Do we do binary kits?
Not yet. The plan is to continue the code/feature freeze with the
21.1 series, except that each 21.1.x won't be considered, announced or
advertised as betas. There will be a 21.1.1 next weekend or shortly
thereafter. There will be a 21.1.2 about a week or so later, and so
forth. We need a new model of dealing with binary kits to take into
account frequent releases.
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>