httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: Going to 2.1? was Re: authentication rewrite
Date Wed, 28 Aug 2002 20:15:52 GMT
On Wed, Aug 28, 2002 at 03:42:53PM -0400, Ryan Bloom wrote:
> Just the same one I've had all along.  Fix it in 2.0.  If it is a major
> config change, then we document it.  We have made changes like this
> before.

I would consider this to be part of 2.0, even if we call it 2.1.
Let me broaden this up a little with some general goals that I
consider to be important. Let's take each of these goals on their
own and consider their merit or feasibility:

1) More frequent releases
   - By making releases more often, we can help foster a healthy
     testing community that can provide valuable feedback and
     eventually improve the quality of the server. We don't need
     to restrict ourselves to the ASF-cabal-approved official release,
     nor the opposite extreme nightly snapshots (which connote no
     amount of quality, stability, or features).

2) Well-defined features
   - There is sort of a catch-22 here. Our volunteer work on features within
     the server can not be constrained by a deadline, but it would be good
     to identify major and minor changes and feature additions and give them
     an appropriately incremented revision number. Later our users can
     go into our documentation and find out, for example, what it means
     when 2.1 has a new authentication framework. (Remember, revision numbers
     are free, but providing clear and precise information to our users
     comes at a steep price.)

3) Fostering a healthy testing community
   - This is one area that I believe the HTTP Server Project has failed
     miserably compared to other projects of equal popularity, at least
     as long as I have been involved. I also believe this is a direct
     result of the failure to identify the above problems. People want
     to play with new features, but they need to know what those features
     are before they start to play. We also have to give them something
     to play with, which means rapid-fire releases with well-documented

In the short term I propose the following:

1) We start work on a new auth framework in whatever way is most comfortable
   for those who will work on it -- either in the 2.0 tree or in a branch
   or whatever. (Ideally we don't break the config on this rather large
   piece without at least a minor-revision bump.)
2) We target the auth features for a release we will call 2.1
3) We maintain this pace for any new features that arise, and decide
   on a per-feature bases whether it fits in the current minor revision,
   in a new minor-revision, or in a new major-revision.


View raw message