Nicolas Lehuen wrote:
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).
I'm not sure we need *alot* of testing on *nix. The
APR_STATUS_IS_SUCCESS macro is not an issue there, since it is defined
as (rc == APR_SUCCESS), which is the change we've made anyway. That
macro does have a different definition on Win32, so that's where the
testing needs to happen. But if there is no Apache 2.2 for Win32, where
does that leave us wrt to a release? After Graham's digging and the
comments from Justin I'm much less concerned about a potential problem
on Win32.
I don't think we should pile a large number of changes in any given
3.2.x bugfix release. If each release has not deviated too much from the
previous version, then we'll need to do less testing and can release
more frequently. I'd hate to see us wait 2 or 3 months for 3.2.8 and
find we have so many bug fixes, and "little" feature additions that we
then need to go through another 3.2.8 beta cycle. Release early and
release often.
Jim
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
