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
features.
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.
-aaron
