> > > > No, there is 2.0.28, period. There isn't a 2.0.28-alpha and 2.0.28-beta > > code base. There is one 2.0.28 codebase. You could have different versions > > if the alpha/beta distinction was in the code, but it isn't. It is only in the tarball > > name. > > I'm with Ryan. 2.0.28 is exactly that. alpha and beta are *designations*. > They are not code changes. > > 2.0.28 should be buildable from the label. If the CHANGES file was modified > *outside* of that, then we have a problem. > > Ship the damned code. This is a BETA for crying out loud. We don't need to > weasel patches in. "oh, just this one little fix." Fuck that. Beta means > bugs. Beta means that we have a list of issues for people to be concerned > with. Beta means people may have platform-specific problems. Beta is not GA. > > +1 on beta. Get a release out the door. Christ almighty... what's it take > around here? The new release process was intended to get tarballs *out* to > people. Not to be held up in a bunch of snippy little bug fix this, bug fix > that. Ship it out with bugs. Call it alpha if it doesn't feel right. Call it > beta if it feels good. > > If an ErrorDocument doesn't work in one case, then tell people "too bad. > don't do that". If the server dies with a particular subrequest executed > from some wonky CGI-provided SSI document, then say "get this patch." But we > gotta get more releases out into the public's hands. > > 2.0.16 was crap. Should people really be using that? Not a chance. > > Give them 2.0.28. > > -g >
+++++1 :-) Bill
