What will be in Django 1.2?

GeoDjango

Schedule

Major milestones along the way to 1.2 are scheduled below. See Process,
below, for more details.

October 20, 2009

Voting on proposals ends. Priority list for 1.2 features
announced shortly thereafter.

November 30, 2009

Progress assessment; final 1.2 feature list.

December 22, 2009

Django 1.2 alpha; major feature freeze.

January 26, 2010

Django 1.2 beta; complete feature freeze.

March 2, 2010

Django 1.2 RC 1; translation string freeze.

March 9, 2010

Django 1.2 final (or RC 2, if needed).

Process

We've tweaked the process slightly since Django 1.1 to try to avoid schedule
slippage. If you helped out with 1.1 most of the following should be relatively
similar; the major difference is the dropping of the idea of "must-have"
features. The purpose of feature triage, this time around, will simply be to
help people focus work on highly-desired areas; any code not complete by feature
freeze dates simply won't make it into 1.2.

Proposal voting

The voting phase needs to achieve two things:

Design Decision Needed (DDN) triage work on proposed tickets. This is the
+1/+0/-0/-1 vote. These votes mean:

+1 - Love the idea, want want

+0 - Ok with the idea, but wouldn't mind if it doesn't happen

-0 - Not really in favor but won't stand in the way of it

-1 - Hell no.

Nominating tickets that someone is personally willing to commit to.

In the up/down voting, we're trying to do pure DDN work. +1 doesn't mean "I'd
like this in v1.2", it means "I like this idea and I'd like it in Django". It
doesn't include any estimation of the likelihood that the patch will be finished
(e.g., Simon's logging proposal). If you think a feature should be in v1.2, you
need to commit to working on it. There's no way to vote against an idea for
v1.2 - you are either against an idea completely, or for it but not willing to
work on it yourself for v1.2.

Once voting is complete, we collate (and possibly massage) the results, modify
tickets to reflect the accepted/rejected status, and we announce the feature
list using the following categories:

High Priority: A core developer is actively engaged in the ticket.

Medium Priority: A core developer is interested in the ticket, but requires
someone to do the work.

Low priority: No core developer has declared a specific interest, but if a
good implementation appears, that may change.

The voting process plus the use of "High Priority" rather than "Must have" aims
to reflect the reality of Django development. Any finished code will be
committed, regardless of schedule. If a feature still needs some design work,
that's fine - as long as the work is done by the feature freeze.

For a feature to make "high" or "medium" priority, a feature needs to have a
"lieutenant" (a term stolen from the Linux community) and a committer
associated. 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. We'll keep track of who these folks are over at Version1.2Features.

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.

Progress assessment

Around the end of November, we will take a look at progress and make a call on
which high-priority items are likely to make the cut. This is the date at which
finalize the v1.2 feature list, and we work out whether we need to adjust our
deadlines.

If we decide to slip the schedule, this is when that decision will be made. If
we decide to stick with the original schedule, we'll commit to dropping features
to hit the deadlines.

Feature freeze / Alpha 1

As with v1.1, all major features must be committed by the Alpha 1 deadline. Any
work not done by this point will be deferred or dropped.

Beta 1

As with v1.1, Beta 1 marks the end of any feature work. Only bug fixes will be
allowed in after this point.

RC 1

Again, no change here. RC 1 will, Murphy willing, be a true release candidate:
1.2 final should be identical to RC 1. RC 1 also marks string freeze;
translators will have roughly a week to submit updated translations for
inclusion in the final release.

Release

Django 1.2 final will ship one week after the last RC. Hopefully we'll only need
a single RC, so, the final release will follow roughly a week after RC 1. If
blockers are found, another RC will be released instead.

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

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

Organize tickets.

Feature tickets should go in the "1.2 alpha" or "1.2 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.2; those should be in the "1.2"
milestone.