1. Until recently, we didn't have a stable Django release series on
   which to begin considering the process of dropping support in
   anticipation of Python 3.0.

2. Python 3.0 isn't available yet.

But now that we have 1.0 (and 1.0.1, and 1.0.2) out the door and 1.1
in planning, and now that Python 3.0 is imminent, I'm going to dump
out my thoughts on the matter in a semi-organized fashion. If you want
to skip the boring bits and just read the conclusion, scroll down.

Now.

The first thing which comes to my mind is a simple question: who's
still stuck with Python 2.3? Anyone whose only option is 2.3 will,
obviously, no longer be able to use Django if we drop 2.3 support and
I'd hate to strand people who want to use Django but don't have the
ability to deploy on a more recent Python. This is also, IMHO, the
strongest argument in favor of maintaining 2.3 support for as long as
possible.

Availability of Python 2.4-compatible platforms
===============================================

So to get things rolling, I spent some time researching the (C)Python
version supported by various alternative Python implementations and
operating systems. What I ended up with is, of course, an incomplete
list, but I think I've at least hit all the major platforms we need to
worry about.

First up, the alternative Python implementations:

* Jython: Jython 2.2.x is roughly equivalent to CPython 2.2, and
  Django has never run on CPython 2.2 so that's a wash. The upcoming
  Jython 2.5 will be roughly equivalent to CPython 2.5, and so
  dropping CPython 2.3 support will not affect users of Jython.

* IronPython: IronPython 1.0.x and 1.1.x seem to be (someone correct
  me if I'm wrong) roughly equivalent to CPython 2.4, and the
  forthcoming IronPython 2.x will be roughly equivalent to CPython
  2.5. So dropping CPython 2.3 support will not affect users of
  IronPython.

Then there are the operating systems:

* Windows: Windows doesn't ship Python, so developers wishing to use
  Django on Windows will need to install Python and will, presumably,
  grab the latest Python they can get. Dropping 2.3 support, then, is
  unlikely to affect Windows users.

* Mac OS X: OS X 10.3 (Panther) and 10.4 (Tiger) shipped Python 2.3;
  10.5 (Leopard) shipped Python 2.5. Thus, dropping 2.3 support may
  pose a problem for OS X users who have neither upgraded to Leopard
  nor installed a more recent Python build (but, of course, a number
  of useful/necessary bits to go with Django are difficult or
  impossible to build on stock OS X, so I'd imagine most people using
  Django on pre-Leopard OS X have installed their own Python,
  presumably a more recent version).

* Red Hat Enterprise Linux/CentOS: RHEL 5 / CentOS 5 ship Python
  2.4. RHEL 4 / CentOS 4 ship Python 2.3. Earlier versions appear to
  have shipped Python 2.2 or older, making this moot for versions
  prior to RHEL / CentOS 4, but there's more to consider here than
  will fit in a bullet point (see below).

* Fedora Linux: Python 2.4 appears to be available for releases back
  to Fedora 6. The current release is Fedora 10.

* Debian GNU/Linux: Current Debian stable (Etch) ships Python 2.4.

* Ubuntu Linux: Ubuntu Linux 6.06 LTS (Dapper Drake), the oldest
  currently-supported release, shipped Python 2.4.

* SUSE Linux Enterprise: SUSE LE 10 ships Python 2.4. SUSE LE 9
  shipped Python 2.3.

* openSUSE: openSUSE 10.2 shipped Python 2.5.

* Solaris: I'm unable to find information detailing which Python
  version ships with various releases of Solaris and OpenSolaris. If
  anyone has that information, please post it in a reply.

* NetBSD: Python 2.4 appears to have first become available in the
  ports tree for NetBSD 2.1. The current release of NetBSD is 4.0.1.

* FreeBSD: Python 2.4 appears to have first become available in the
  ports tree for FreeBSD 4.11. The current release of FreeBSD is 7.0.

* OpenBSD: Python 2.4 is available for the current release of OpenBSD
  (4.4). I'm unable to find historical information detailing when
  Python 2.4 first became available in the OpenBSD ports tree.

What this all means, part 1
===========================

For the overwhelming majority of platforms in the above lists,
dropping 2.3 compatibility should pose no problem, because 2.4 or
later (or 2.4-compatible or later) are available. This is the good
news.

The bad news is contained simply in the list of platforms which won't
fare so well if we drop Python 2.3 support:

* Red Hat Enterprise Linux 4 / CentOS 4

* SUSE Linux Enterprise 9

I don't know offhand how widely Django is deployed on SUSE LE 9, but I
know from experience that a *lot* of corporate Django deployment takes
place on RHEL 4 / CentOS 4. That's a problem in and of itself, but it
gets worse when you take into account the fact that many of those
deployments cannot, in effect, upgrade to a more recent Python version
without voiding their support contracts (of course, in theory they can
install and maintain a more recent Python in parallel, but in practice
this is more trouble than it's worth).

Oh, and one more bit of doom and gloom: RHEL / CentOS supports
releases for seven years, meaning RHEL 4 / CentOS 4 will not reach
end-of-life until 2012.

Thus, the only way users of these platforms will be able to use a
Django release which drops 2.3 compatibility is by upgrading to RHEL 5
/ CentOS 5 or later and, of course, corporate deployments are
notoriously rather conservative about such upgrades.

Also, note that the argument, raised multiple times already, about
upstream support from Python itself for 2.3 is moot; distributions
like RHEL which ship Python 2.3 are committed to supporting it until
their own EOL dates regardless of what upstream Python does.

A pop-culture segue
===================

Many of you have perhaps seen the 1990 film adaptation of Tom Clancy's
novel "The Hunt for Red October", which concerns a Soviet
nuclear-missile submarine whose captain and officers are attempting to
defect. The protagonist, American CIA analyst Jack Ryan, is in one
scene mulling how to remove the crew from the submarine without making
them aware of their officers' intentions:

    Wait a minute. We don't have to figure out how to get the crew off
    the sub. He's already done that, he would have had to. All we
    gotta do is figure out what he's gonna do. So how's he gonna get
    the crew off the sub? They have to want to get off. How do you get
    a crew to want to get off a submarine? How do you get a crew to
    want to get off a nuclear sub...

At this point, our intrepid hero has an epiphany and is able to
formulate a plan for action.

What this all means, part 2
===========================

In short: we don't have to figure out how to get "enterprise"
deployments to upgrade. All we have to figure out is how those
deployments are going to get into a situation where they *want* to
upgrade. And the answer is, simply, Python 3.0.

Over the next year or two, an ever-increasing amount of Python
software will be going through the same process we're currently
contemplating: dropping support for Python versions in anticipation of
eventually running either only on Python 3.0, or on Python 3.0 and
Python 2.6. So even though RHEL 4 (for example) won't EOL until 2012,
the point at which the scarcity of available and useful software
running on Python 2.3 will become a suitable upgrade incentive will
likely occur much sooner.

In other words, a time will come, possibly fairly soon, when these
folks will want to "get off the boat" of their own accord. And so we
probably don't need to worry too much about it right now.

A schedule for dropping Python 2.x support
==========================================

The only thing left, then, is to decide on a timeline for dropping our
support for various 2.x Python releases. I don't entirely agree with
the proposal to drop 2.3 immediately with Django 1.1, because I'd
prefer to give users and distributors of Django a bit more warning;
dropping support for a Python version is the sort of thing which
really needs to involve more than (at this point) four months' advance
notice, so that people who are affected will have enough time to start
planning upgrades and migrations.

Additionally, for platforms which support multiple parallel Python
versions on the same system (e.g., Debian's python-support system),
giving a bit more lead time is important so that their packaging
processes can test and update dependencies for Django and related
software.

So I'd like to propose an alternative: we provide one full release
cycle's advance warning before we drop support for an older Python
version.

This would mean the earliest we could drop Python 2.3 would be Django
1.2, and I'd envision the progression going something like this
(assuming two Django releases per year, a not-unreasonable supposition
at this point):

* First half of 2009: Django 1.1 is released, with a notification that
  it will be the final release supporting Python 2.3.

* Second half of 2009: Django 1.2 is released, drops Python 2.3
  support and is the final release supporting Python 2.4.

* First half of 2010: Django 1.3 is released, drops Python 2.4 support
  and is the final release supporting Python 2.5.

* Second half of 2010: Django 1.4 is released and drops Python 2.5
  support.

This gets us to a situation where, about a year after the release of
Python 3.0, Django will be ready to make the transition -- the only
2.x Python we'll be supporting is Python 2.6, and 2to3 plus manual
effort and available supporting libraries should make it possible to
also run Django on Python 3.0 either at that point or not long after.

From there, 2.6 support can be dropped whenever convenient, and Django
can move to running only on Python 3.x at whatever time is judged
appropriate.

If we end up doing a few longer (e.g., 9-month instead of 6-month)
release cycles, obviously that point will be pushed back further into
2010, but I think that's perfectly acceptable.

This also has the advantage of giving existing and prospective Django
deployments a longer-term timeline to refer to; there are plenty of
places where an operating-system upgrade needs more than six months'
advance planning, and being able to know well ahead of time when their
current platform will lose official Django support will likely help
those places considerably.

Implications for Django development
===================================

The biggest issue I can see for this, in terms of Django's own
development, is how to maintain the parallel bugfixes/feature
development system we've committed to. If, for example, we release
Django 1.2 with the intention that it will be the final 2.4-compatible
release, we'll need to ensure that any backported fixes into 1.2.x
releases still maintain that compatibility.

This probably won't be too difficult, since it doesn't seem likely
that we'll be doing major rewrites of the Django codebase to take
advantage of more recent Python features. Rather, incompatibilities
with unsupported Python versions will simply enter the codebase when
they make sense as improvements to Django. So this isn't likely to be
a big issue.

Implications for Django distribution and community support
==========================================================

Finally, none of this should be taken to mean that it must become
impossible for Django to continue running on older Python releases;
rather, the only change will be that the core Django development team
will no longer support that use case and will no longer take care to
preserve compatibility with older Python releases.

Since, as I've mentioned above, there are already Linux distributions
committed to maintaining Python 2.3 support for several years into the
future, I wouldn't be surprised if motivated distributors and members
of the community continue to organize and provide their own support
for Django on older Python releases, independently of what we
officially do. A similar situation already exists in terms of older
Django releases which no longer receive official support, but which
several people, myself included, have continued to patch on our own as
part of our duties to our employers or our employers' clients.

So if there are (and I suspect there will be) enough people interested
in maintaining unofficial Django source trees or packages which
continue compatibility for particular Python versions after we've
officially dropped support for those versions, I don't think we should
(or can -- this is open-source software, after all) get in their way.

The only problem I can foresee there is how to handle the need to call
those unofficial, unsupported codebases "Django". I'd really like to
avoid getting into the nasty, community-goodwill-killing situations
trademark issues can cause (see Mozilla for a shining example of how
*not* to protect an open-source trademark), so maybe the DSF could put
some its funds to use by chatting with an attorney about the best way
to deal with that.

Conclusions
===========

So, as promised, that ended up being pretty long. But here are the
salient points:

* We shouldn't worry too much about platforms which still only offer
  Python 2.3, because people on those platforms will end up with their
  own incentive to upgrade as various Python projects drop support in
  the run up to Python 3.0 migration.

* We shouldn't drop Python 2.3 support in Django 1.1; the earliest we
  should do that is Django 1.2, and we should provide a timeline
  explaining how we'll proceed from there to dropping other 2.x Python
  versions.

* Dropping 2.x Python versions as we go probably won't cause any major
  headaches, just an occasional need to be careful when backporting a
  bugfix.

* Even after Django officially drops support for a particular Python
  version, that shouldn't necessarily be the end of the line; people
  who want or need to continue maintaining support on their own can
  and should be able to.

And... I'm spent.