Django 1.2 Roadmap

This document will eventually detail the schedule and roadmap towards Django 1.2. For the moment, it's a placeholder.

What will be in Django 1.2?

Proposals for feature additions in Django 1.2 are now open - add your proposal to the wiki .

GeoDjango

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

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.2Features 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:

• 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!