Django 1.2 Roadmap

This document details the schedule and roadmap towards Django 1.2. Django 1.2 is currently in the final stages of preparation.

[Update: May 5, 2010] The Release Candidate was released on May 5; the estimated date for the final release is May 12.

What will be in Django 1.2?

Whatever gets committed by January 5th!

Django 1.2 will be a fully time-based release; any features completed and checked in by the feature freeze deadline (January 5th) will be included. Any that miss the deadline won't. The Django core team has prepared a list of prioritized features for 1.2 to help direct our development resources, but the list is more of a guideline than a hard and fast feature list.

GeoDjango

1.2 features for GeoDjango are being coordinated on the wiki and the GeoDjango mailing list.

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.
January 5, 2010	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.

Certain features may be not-well-enough-specified for a complete vote. That's okay; we'll also allow an "abstain/defer" vote, which basically means "I don't have enough information to vote for or against this proposal yet." Features in that category will simply stay "design decision needed" until there's enough information to make a call.

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:

• Read the guide to contributing to Django and the guide to Django's release process.

  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.

• Test the release snapshots (alphas, betas) against your code and report bugs.

  We need lots of testers if we're to have a bug-free release. Download a snapshot or an SVN checkout and give it a try!