Based on today's traffic on the mailing lists, I think that we should go for a short-term 3.2.8 release of mod_python, with certified Apache 2.2 support on multiple platforms. The code is only there but I suppose we'll need a lot of testing, so maybe we could expect to release this in a month or two (given that the Win32 source code is not even available right now).
Regards, Nicolas 2006/2/14, Nicolas Lehuen <[EMAIL PROTECTED]>: > 2006/2/14, Graham Dumpleton <[EMAIL PROTECTED]>: > [...] > > If we want to go down the path of having interim 3.2 bug rollup releases > > while 3.3 is being developed, might I suggest that we target the following > > for such a release in the near future. > > > > MODPYTHON-77 > > > > The Simplified GIL Aquisition patches. > > > > MODPYTHON-78 > > > > Apache 2.2 patches. > > > > MODPYTHON-94 > > > > Support for optional mod_ssl functions on request object. > > > > MODPYTHON-113 > > > > Make PythonImport use apache.import_module() via CallBack method. > > > > MODPYTHON-119 > > > > DBM Session test patches. > > > > MODPYTHON-122 > > > > Bash 3.1.X configure patches. > > > > I know that MODPYTHON-94 isn't a bug fix, but a few people have been after > > this one. Also MODPYTHON-113 may not seem important, but will mean > > that any test package I make available for new importer will work properly > > in all cases where module imports occur. > > > > Anyway, after trolling through JIRA, these seemed to be the important ones > > to me, but other might have other suggestions. > > > > Now, the question is how we manage this. Do we concentrate on these only > > in the trunk and get them out of the way first as a 3.2.X release, holding > > back > > any changes to test framework? Or do we merge such changes from trunk on > > a case by case basis in 3.2.X branch? > > > > Graham > > > > I was thinking about working on the new test framework in parallel of > "real work", away from the trunk (in my /branches/nlehuen directory). > I don't think it will be too hard to track down the changes in the > trunk tests and bring them back in the new test framework, but I may > be wrong. One the new tests are available, I'll merge them back in the > trunk. > > So I guess it's not necessary to hold back the next release do to the > tests, and it may be a good exercise to due a few 3.2.x releases in a > short period of time before doing the 3.3.x release. > > Regards, > Nicolas >
