Ok, [overly?] provocative title. Let me illustrate, however; http://httpd.apache.org/docs-2.0/mod/
See any authn_foo/authz_foo? No, not at the moment. Once we do, how on this green earth do we propose to provide online docs for 2.0.43 and a hypothetical 2.0.44 with the auth overhaul? Folks come back to http://httpd.apache.org/ to answer their questions, and completely deprecating and removing stuff mid-sub-revision is cruel and unusual punishment. My best guess? It won't make any sense. We often add modules during the lifetime of a revision, e.g. in 1.3 we added mod_auth_digest in rev 1.3.8. But we didn't clobber the old standby mod_digest then. That waited for 2.0. I cannot see how we can make this transition modestly painless for administrators while providing some semblance of working docs for both the pre and post auth overhaul. It just doesn't compute. Version numbers are cheap. 2.1 reinforces that 2.x is ready for the big time on many platforms (and is fact already working for cnet and may other massive volume providers today.) It allows us to clean up those lingering bits that really bug us, without adding confusion to 3rd party module author's lives. I'm calling for a consensus opinion that the mod_auth changes are simply too radical to introduce into a current version. We keep treating the GA tree as a development branch. Many newcomers (with less than a couple of years here in httpd land) and a very few old timers persist in doing so. We should treat 2.0 as done. Cooked. Baked. Cooling off. Let's get moving on 2.1 so we can build on Justin's very worthwhile rewrite of mod_auth. I'm not criticizing it. I'm criticizing the amount of work to move a running server to the new schema, and the amount of information necessary to convey to users how to deal with this change. Where did the directives go? Which module is which? What does what? These are questions hard to answer in /docs-2.0/ while still providing the information for 2.0.43 and prior users. There is too much curve here for a smooth transition, although the transition is certainly good. Folks bumping by a major or even minor revision expect a little (temporary) hardship. But when bumping by a subversion? That's too much. Let's get cracking and we can have a 2.1 release out by year end, depending on how far we go with changes in that version. Certainly some of the file-based stuff can finally be separated out, even if not as radically as GStein has proposed. 2.0 is good, and should continue to be bugfixed for many months. But with 2.1, we can let people start adopting threaded modules with worker and really let the 3rd party module authors settle in to dealing with the threading issues, instead of oddball API changes. Bill
