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

Django 1.0 will be released in early September.

To meet that deadline, Django 1.0 has a minimal set of `must-have
features_. The big feature on that list is newforms-admin`.

There's a larger set of "maybe" features_: if these features are done
by the 1.0 feature-freeze date (August 5), they'll be included in 1.0.

Those who want to help out should read the rest of the document, and
especially how you can help_.

You can follow the status of this project at the
:trac:VersionOneFeatures page.

dates_

.. contents:: Table of Contents

What will be in 1.0?
======================

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:

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.

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*.

"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.

"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.

Must-have features

DONE:newforms-admin.

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

DONE: Replacement of oldforms throughout Django.

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 :trac:[8616].)

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

DONE: Making Django 100% WSGI compliant.

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

on comments_

"Maybe" features

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).

Fix all known bugs preventing Django from running on alternate Python
implementations. In practice this means fixing any bugs filed before 1.0 beta
from people working on running Django on an alternate VM.

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

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.

The good news is that it'll make a kick-ass 1.1 feature!

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.

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 features not on this list.

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.

Schedule
========

Django 1.0 will be released in early September.

The general release process will be:

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.

The alpha release will also promote any "pending deprecation" warnings to
full-blown deprecation warnings.

Two beta releases.

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.

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.

A final release.

A big-ass party.

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

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.

Dates

For details on the 1.0 sprints, see the :trac:wiki:Sprints page.

============== ===============================================================
July 10-12 newforms-admin sprint in person at EuroPython_ and around

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 :trac: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.

How you can help

The only way we'll meet this deadline is with a great deal of community effort.
To that end, here's how you can help:

Read the guide to contributing to Django.

This guide explains how our process works. where to ask questions, etc.
It'll save everyone time if we're all on the same page when it comes to
process.

Work on features from the list above.

Get in touch with the lieutenant/committer for the feature you'd like
to work on and help out. Or just find open tickets and start submitting
patches!

The joy of Open Source is that nobody gets to tell you what to do; you
can scratch whichever itch you like. However, if you work on items *not*
on the list of 1.0 features, you should expect that your patch won't get
checked in until after 1.0.

Attend a sprint (in person or in IRC).

We'll have about a half dozen sprints between now and the final 1.0
release. Lots of work gets done at sprints, and there's usually someone
around willing to help new developers get started.

Organize tickets.

Must-have feature bugs go in the "1.0 alpha" milestone. These basically
should be all nfa-blocker tickets. Bugs in the must-have features
are not to be part of this milestone; they can be fixed after the
alpha and should be put in the "1.0" milestone.

Any feature tickets related to the maybe list get put in the "1.0 beta"
milestone.

django.contrib.comments is a bit of special case. Ideally, Django 1.0 will
ship with *no* core use of oldforms. However, refactoring the entire comment
system -- not just replacing forms -- is overdue, and is the subject of a Google
Summer of Code project. So it would be silly to simply replace the form use when
the whole package is scheduled to be replaced.

August 11 is the suggested pencils down date for GSoC. This means that if
Thejaswi (the student working on comments for GSoC) is on track, he will be
completed around the time of the beta 2 freeze date. July 14 is the midterm
evaluation date for Summer of Code; we should be able to get a good idea then
whether completion on schedule is likely.

If the midterm evaluation says that the project is going badly, we'll abandon
ship and simply replace the form components in the current contrib.comments
with newforms; we'll ship the new comment library in a future release.

If the midterm evaluation is positive -- which is highly likely -- we'll work on
the assumption that the new comment framework will be merged intro trunk before
the beta 2 release (and possible earlier, if Thejaswi has something ready).
We'll encourage people to push the new framework pretty hard, especially during
sprints.

If we get to August 11 and we don't have a release candidate, we can simply
release with oldforms comments: it'll be annoying but not a deal-breaker.

On file storage

In addition to the :trac:#5361 primary ticket, the patch implementing file
storage improvements also rolls in fixes to several other tickets. All of these
tickets are tagged with a keyword of fs-rf-fixed_, and should be referenced
as fixed in the commit message when the patch is committed to trunk.

Another goal of this patch is to open up additional possibilities for more granular
handling of things like file and directory names, among others. There are also
several tickets requesting these features, and though these requests won't be
directly resolved, the patch will allow them to added on a per-site or even
per-app basis. As such, these tickets are tagged with fs-rf-docs_, indicating
that the documentation included with the patch will explain how these features can
be added outside of core.