|Version 12 (modified by russellm, 4 years ago) (diff)|
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: March 16, 2010] The estimated release date for RC1 is April 5, with the final release on April 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.
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).|
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.
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.
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.
As with v1.1, Beta 1 marks the end of any feature work. Only bug fixes will be allowed in after this point.
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.
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).
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!