OK, so shall we schedule the 3.2.x release for 2007, then ? As for the Apache 2.2 version, what if we roll in your suggested patch, Jim, then discover a bunch of problem related to it during the beta tests ? Will we wait until they are all fixed to release the 3.2 version ? Apache 2.2 is quite new so we'll likely to have to squish bugs, due for example to new interaction between Apache filters and mod_python. That's a wild guess but filters have been modified in Apache 2.2 so I'm sure something evil lurks there.
<bitter>Or we could simply forget about making the release one day and tell every user to use the latest snapshot from subversion. Sorry to be like that, but we have users out there that would be perfectly happy with the current state of the 3.2.6 version, and a lot of our answers on the mailing list are "yup, we know this bug, it's already been fixed one year ago, but don't worry, you'll get the bugfix soon enough".</bitter> Once again, it seems that no regression have been introduced in 3.2.6 vs 3.1.4, so we should release it ASAP and try to keep a steady release rythm afterwards. When we'll get momentum we'll solve a bunch of problem pretty fast, but it's been a year now that we are paralysed by perfectionism. What could be worse than leaving our users out there with the current 3.1.4 version ? Regards, Nicolas 2006/1/31, Jim Gallacher <[EMAIL PROTECTED]>: > I assume we will be doing a 3.2.7 release if Graham's fix for the > ConnectionHandler / MODPYTHON-102 problem works? > > If that is the case I wonder if we should roll in the changes to support > apache 2.2. I scanned mod_python for deprecated or removed apr calls and > can find only one (apr_sockaddr_port_get), plus the missing > APR_STATUS_IS_SUCCESS macro. > > The original macro is: > > #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \ > || (s) == APR_OS_START_SYSERR + NO_ERROR) > > > The discussion on httpd-dev suggested that this macro should be > substituted with a simple test such as "if (rc != APR_SUCCESS)", and the > '||' condition was not likely used. So that we are making the fewest > possible changes to our current 3.2 codebase, I'd suggest reimplenting > APR_STATUS_IS_SUCCESS in our code, and then removing it 3.3. This will > give us lot's of time as we work on 3.3 to discover if there are any > problems droping the APR_OS_START_SYSERR part of the test. > > Jim >
