After a million messages on related topics, I'm not sure that any two
developers agree on all of the following topics:
. how much to consider the needs of users relative to desires of
developers
. how hard to try not to break binary compatibility
. how much to use 2.0 HEAD as a sandbox for new features
. whether or not to start 2.1 now for auth changes
Meanwhile, a number of the 2.0 users which have dared poke their heads
into our mailing list point out through their comments that we have a
PR problem (regardless of whether or not you agree technically on
their particular concerns).
I would like to propose the following:
. let 2.0 HEAD proceed as it seems to be going now... maybe not
everybody is happy about every aspect but the way it is handled is
rough consensus of developers... I'm not saying this is wrong, but
I think that the volatility of 2.0 HEAD + APR HEAD is high enough
that it is hard to put out a good release quickly unless we're very
conservative and put something out with just a couple of changes
beyond 2.0.43
. let those who are interested (not more than a few would be needed to
make it viable) maintain a separate tree based on 2.0.43, including
apr and apr-util... call it httpd-2.0.43, with potential releases
2.0.43.1, 2.0.43.2, etc.
priorities would be
. quick integration of critical fixes from HEAD
. skepticism regarding any changes other than critical fixes; for
some fixes it would be best to wait to see if any users of the
stable tree actually encounter the problem
. maintaining the MMN
starting this now would let folks with modules from 2.0.41-2.0.43
continue to work into the future, even if they need to pick up a
security fix in Apache, even if 2.0 HEAD needs to bump MMN
tomorrow
When it becomes impractical to achieve these goals with 2.0.43 code
(e.g., a critical problem can't reliably be fixed without bumping
MMN), then it is time to discard this particular stable tree and
tell folks to move to the current release to get new fixes. If
there are still concerns about volatility in 2.0 HEAD at that point
then there will be a need for another stable tree.
Note: There are ways other than a separate CVS tree to implement the
same objective. Rather than pick on the mechanism, the first order of
business is to address the ability for some of us to make releases
with such a conservative set of changes. Then we (hopefully comprised
mostly of people who plan to do the work) can worry about how it
should be done.
(grabbing flak jacket)
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
