This document details the schedule and roadmap towards Django 1.0. All the details are below, but here's the executive summary:

We want to ship bug-free, so we'll dedicate as much of our time to bug stomping as possible. This means that feature requests will need to be deferred.

Any additional database backends. Again, the overhead in integrating a new database backend is too much. These will need to remain external backends until after 1.0.

Any other additions to django.contrib . Though there are many nice candidates out there, we simply don't have time to roll them into Django in time for a release. We'll come up with a "contrib process" post-1.0 and start looking at this then.

Aggregation support. Although this is a Summer of Code project that's looking very promising, the timeline for SoC won't fit with the aggressive schedule we're setting for 1.0. Further, it's a "dangerous" change in that it modifies parts of Django's query engine, and that needs to be rock-solid for a 1.0 release.

Unfortunately, the only way to get this done is to say no a lot. Let's start now:

Again, these are features that should be in 1.0. In most cases, they're actively being worked on by members of the development community and simply need focus by committers (more about how that process will work below).

This simply involves fixing ticket #285 . We've delayed doing this to avoid the backwards-incompatible change, but we must make this change before 1.0. (Committed in [8015] .)

django.contrib.comments still uses oldforms as well, but is a bit of a special case .

Nothing in Django 1.0 should rely on the deprecated oldforms package. We'll need to replace oldforms usage in generic views, and in django.contrib.auth . (Committed in [8616] .)

It's clear from discussion on this list that most consider a release without newforms-admin to be a bad idea. (Committed in [7967] .)

"No" features: things that specifically will not be in 1.0, and which we'll ask developers not to focus on. We need to trim down to hit dates, after all.

"Maybe" features: things that should be in 1.0 and should be worked on in the run up to the release. If, however, features on this list aren't completed, they will be dropped.

This of course means that these features are the "A" features, and we'll ask anyone who can help to focus on these features first.

Must-haves: features that, if not completed, are worth delaying the release. That is, if the work on this list is not completed by a release date, we'll push the date.

The primary reason we've not yet released 1.0 is the long feature wish-list. We need to balance this list of features against the need for a timely release and speedy process. To that end, we'll categorize all the features of 1.0 thusly:

All the releases until 1.0 will be "snapshot" releases: we won't be backporting fixes -- even security fixes -- but will just be fixing bugs in the next release.

We will hold development sprints in between each release to focus on the next release.

At least one -- and hopefully only one -- release candidate. The candidate release will mark a total freeze (as well as a string freeze for translators); only outright bug fixes will be accepted past this point.

All "maybe" features must be completed by the first beta; after that, Django will enter feature freeze for about a month while we kill bugs.

An alpha release containing all must-have features, but likely not bug-free. We'll push hard to have all the must-haves done in time for ample testing.

Each feature on the list (both "must-have" and "maybe") will have a "lieutenant" (to steal of term from the Linux community) and a committer assigned. It's OK if this is the same person, but the idea is that one committer can keep an eye and commit from patches from a number of trusted lieutenants. In most cases, the features on the todo list have obvious lieutenants; we'll need to assign missing ones and also committers. See VersionOneFeatures for the current list of lieutenants and committers.

James, as the release manager, will be in charge of keeping the schedule. He'll keep track of who's working on what issues so that bug reports can be efficiently routed; he'll also nag, cajole and (if necessary) berate developers who are in danger of missing deadlines.

Once 1.0 is out we'll appoint a "version manager". This person will be responsible for maintaining the 1.0 release series, which means backporting security fixes and "important" bugs and releasing 1.0.1, etc.

Similarly, we'll appoint a 0.96 version manger who will do the same with 0.96. We'll continue to support 0.96 until 1.1 ships.

With the 1.0 release, however, we will stop support 0.95 and earlier. This is somewhat flexible; if someone has a stake in one of those older versions we'll happily let them continue to maintain those releases, but if nobody steps up the core team won't be able to do it.