|Version 1 (modified by 6 years ago) (diff),|
Django 1.3 Roadmap
This document details the roadmap for the release of Django 1.3.
What will be in Django 1.3?
Whatever gets committed by November 29th!
Django 1.3 will be a time-based release; any features completed and checked in by the feature freeze deadline (November 29th) will be included. Any that miss the deadline won't.
The main focus of major feature development will be features that didn't make the cut for v1.2, such as:
- #12012 - Logging
- #6735 - Class-based generic views
However, the focus of Django 1.3 isn't to add lots of big new features. The last two Django releases have added lots of features, and the little things have suffered as a result. The intention of the 1.3 release is to focus on fixing bugs and adding the low priority and minor features that haven't got as much attention.
Major milestones along the way to 1.3 are scheduled below. See Process, below, for more details.
|October 18, 2010||Django 1.3 alpha; major feature freeze.|
|November 29, 2010||Django 1.3 beta; complete feature freeze.|
|January 10, 2011||Django 1.3 RC 1; translation string freeze.|
|January 17, 2011||Django 1.3 final (or RC 2, if needed).|
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.
Feature freeze / Alpha 1
As with v1.2, 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.2, 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.3 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.3 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.
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 big feature items, you should expect that your patch won't get checked in until after 1.3.
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!
Write and review patches.
There are plenty of tickets already on the 1.3 Milestone that either don't have patches, or have patches that need review. Writing, reviewing and improving patches is the best way to make sure that 1.3 has as few bugs as possible.
Attend a sprint (in person or in IRC).
Feature tickets should go in the "1.3 alpha" or "1.3 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.3; those should be in the "1.3" 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!