Update, April 18, 2009: Obviously we've missed the deadline.
There are still a number of open issues to be fixed before
1.1 will be released; we don't want to put out a buggy Django!
We'll update the schedule with a more firm date once we have it.

Update, July 21, 2009: Django v1.1 is now effectively complete. We haven't shut down the v1.1 milestone so that critical bugs can still be drawn to our attention, but there is nothing blocking the v1.1 release at this point. Release Canddiate 1 (RC1) will be cut at some point in the next day or so, allowing translators to do their job on finalized strings. v1.1 final will be released approximately 1 week after the RC is cut.

What will be in Django 1.1?

Over 60 features were proposed for Django 1.1. After discussion by the
development community, these features were categorized "must have", "maybe",
or "no" -- see our official release process for more information on how
this works.

Remember: see Version1.1Features for more details on each feature below;
these are just summaries.

Must-have features

These are the features considered critical for the 1.1 release.

DONE: [Admin-03] Make the admin use a URL resolver. (Committed in [9739])

The following features were reviewed highly and are generally accepted as
"wanted", but currently are lacking a "champion" to see the feature done. This
means these features are likely to be included in 1.1 if finished, but are
a sort of "second-tier":

Special cases

The scope of this feature is a bit nebulous, but it's under discussion
on django-developers. If consensus is reached and the feature can
be implemented in time, it'll get into 1.1.

[Form-01] Selectable HTML output for forms/fields.

This feature is similarly not fully-scoped, though this one has a
reference implementation so it's further along. However, there's a fair
bit of controversy about the particular proposed implementation. Again,
consensus is the issue here; discussion is ongoing.

[View-02] Add RequestContext by default in render_to_response.

This proposal is strongly controversial, with multiple +1 and -1 votes.
As such, consensus seems unlikely; a middle-ground approach will need be
found, which likely pushes this out of scope for 1.1.

Rejected/deferred features

The remaining proposed features were rejected or deferred for a variety of
reasons; see Version1.1Features for a complete list of these rejected
features and reasons for rejection or deferral.

GeoDjango

Schedule

Django 1.1 is beyond deadline at this point. It will be released as soon as it is in good enough
condition to be released. Please help contribute to resolving any issues on the
list of open tickets.

The complete schedule follows. Note that dates are plus or minus a couple of
days as needed:

January 15, 2009

"Major" feature freeze for 1.1; work phase ends, and any
major incomplete features will be postponed.

February 23, 2009

Django 1.1 alpha.

March 23, 2009

Django 1.1 beta. Feature freeze; only bug fixes will be
allowed after this point.

April 2, 2009

Django 1.1 rc 1. and string freeze

April 13, 2009

Django 1.1 final

We'll hold a series of Sprints to work on 1.1 starting in late
December; stay tuned to the Sprints page and/or the
django-developers mailing list for details.

Process

Each feature on the list (both "must-have" and "maybe") will have a
"lieutenant" (a term stolen from the Linux community) and a committer
assigned. It's OK if this is the same person, but it's better if not: one
committer can keep an eye and commit from patches from a number of trusted
lieutenants. See Version1.1Features for the current list of
lieutenants and committers.

James Bennett, 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.

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:

These guides 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.

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.1 features, you should expect that your patch won't get
checked in until after 1.1.

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!

Attend a sprint (in person or in IRC).

We'll have four or five sprints between now and March. Lots of work gets
done at sprints, and there's usually someone around willing to help new
developers get started.

Organize tickets.

Feature tickets should go in the "1.1 alpha" or "1.1 beta" milestone.

Which one? Well, major changes must be made before the alpha, and
minor feature changes before the beta. So "major" feature additions
go in the alpha milestone, and minor additions in the beta one. If
you're not sure, then the feature is minor.

Bugs are not to be part of these milestone; any bug is a
candidate for fixing and should be left un-milestoned. The exception
is bugs in features added for 1.1; those should be in the "1.1"
milestone.