Please document mod_python support drop in release notes

[anonymous]

After upgrading to 1.5, I gave that error:
ImportError: No module named modpython

I would have switch to wsgi before upgrading to 1.5, had I known.

Please do add this important change in release notes.

[Marc Tamlyn]

It had been documented as deprecated in 1.2, 1.3 and 1.4, but nonetheless it should be in the release notes.

[Tim Graham]

We don't typically repeat the list of deprecated features in the release notes, rather just say "We’ve also dropped some features, which are detailed in our deprecation plan" (with deprecation plan linked to the appropriate page). However, I noticed that in the development version of the docs, the deprecation timeline has been truncated so the list of features removed in 1.5 has been removed so if you're reading the 1.5 release notes in a newer version of the docs, you may not be able to find what you're looking for. Thus, we may want to rethink how we structure this.

[anonymous]

I'm reading the 1.5 release notes here:
​https://docs.djangoproject.com/en/1.5/releases/1.5/

1.5 was the first version to drop mod_python support.

Maybe my English is not good enough, but "deprecation plan" sounds like a list of features that becomes deprecated, and whose removal is scheduled sometime in the future.

I maintain 1.5 release notes should says it is broking what used to be one of the best may to deploy django apps, that is dropping mod_python support. First line of that page has a link to "backwards incompatible changes". There is nothing about mod_python there.

(I haven't finish migration to 0.96 version in that big project, yet...)

[anonymous]

Ok, I'm getting confused maybe. Is mod_python supposed to work with 1.5 ?
Maybe this is not a documentation issue.

I'm getting a 500 with that message:

mod_python (pid=4479, interpreter='xxxxxx.com', phase='PythonHandler', handler='django.core.handlers.modpython'): Application error
ServerName: 'xxxxxx.com'
DocumentRoot: '/usr/lib/ngw/static'
URI: '/'
Location: None
Directory: None
Filename: '/usr/lib/ngw/static/'
PathInfo:
Traceback (most recent call last):

File "/usr/lib/python2.7/dist-packages/mod_python/importer.py", line 1537, in HandlerDispatch\n default=default_handler, arg=req, silent=hlist.silent)
File "/usr/lib/python2.7/dist-packages/mod_python/importer.py", line 1202, in _process_target\n module = import_module(module_name, path=path)
File "/usr/lib/python2.7/dist-packages/mod_python/importer.py", line 304, in import_module\n return import(module_name, {}, {}, *)

ImportError: No module named modpython

[anonymous]

mod_python was deprecated in 1.3 and removed in 1.5.

​https://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/#mod-python-support

[anonymous]

mod_python was deprecated in 1.3 and removed in 1.5.
​​https://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/#mod-python-support

Ok. That is correct.

Then:
1.5 release notes should mention that fact in backwards incompatible changes. (​https://docs.djangoproject.com/en/1.5/releases/1.5/)
1.5 deprecation plan should not say "The mod_python request handler will be removed"

[Aymeric Augustin]

We document deprecations when they start. We don't duplicate this information when they complete (DRY!). The deprecation timeline is written in the future tense, because it's intended to be read before the deprecations complete. If you've ignored the deprecation warnings, you shouldn't be surprised when your code breaks.

You could make an argument for structuring our communication differently. That argument belongs to the django-developers mailing-list. It has nothing to do with mod_python. We could have the same discussion about any other feature that got deprecated at any point in the history of Django.

Considering that we've been doing this consistently for years without too much trouble, and that there's value in consistency, we should think twice before making changes. I suspect that someone will always manage to miss the relevant information, regardless of how much effort we put into structuring it. I'd rather aim our docs at the people who read deprecation warnings than those who don't.

[anonymous]

Man, I'm not complaining about my code being broken.

I'm merely saying that mod_python removal would be a nice addition to 1.5 release notes, to improve the overall quality of the documentation (the section that bug was filled in).

This is my last try. I won't argue more. Have it your way.

[Tim Graham]

As I alluded to above, I think we may not want to make removals like [ddd3926280725fc4cedd1c511a95a57db7dde488] if we aren't also removing the corresponding release notes. Otherwise, the link to "deprecation plan" in the sentence from the release notes "We’ve also dropped some features, which are detailed in our deprecation plan" leads to a deprecation plan which doesn't include the notes for that version. To be most helpful, I think we should also link to the specific section of the deprecation plan for each version. Switching the ordering of the deprecation timeline to descending order (oldest release last) like we do for the release notes should help keep more irrelevant things out of the way. Any objections to these changes?

[Aymeric Augustin]

Yes, reworking the deprecation timeline is the most sensible way forward.

We removed obsolete info because it was at the top. If we reverse the order, there's no problem with keeping the entire history. The relevant info will be in the first three sections.

[Tim Graham <timograham@…>]

In d4a5019bef116028edb6e66eac9156da96a3d704:

Reordered deprecation timeline and added back old info; refs #21920.

[Tim Graham]

I'm made the change to the deprecation timeline and added better links to the release notes in the commit above. Closing this ticket as "won't fix" since we are technically not addressing what's in the summary/description of the ticket.