| Version 13 (modified by , 16 years ago) ( diff ) |
|---|
Django 1.0 Roadmap and Schedule
This document details the schedule and roadmap towards Django 1.0. All the details are below, but here's the executive summary:
- Django 1.0 will be released in early September.
- To meet that deadline, Django 1.0 has a minimal set of must-have features. The big feature on that list is newforms-admin.
- There's a larger set of "maybe" features: if these features are done by the 1.0 feature-freeze date (August 5), they'll be included in 1.0.
- Those who want to help out should read the rest of the document, and especially how you can help.
- You can follow the status of this project at the VersionOneFeatures page.
What will be in 1.0?
The primary reason we've not yet released 1.0 is the long feature wish-list. We need to balance this list of features against the need for a timely release and speedy process. To that end, we'll categorize all the features of 1.0 thusly:
Must-haves: features that, if not completed, are worth delaying the release. That is, if the work on this list is not completed by a release date, we'll push the date.
This of course means that these features are the "A" features, and we'll ask anyone who can help to focus on these features first.
"Maybe" features: things that should be in 1.0 and should be worked on in the run up to the release. If, however, features on this list aren't completed, they will be dropped.
"No" features: things that specifically will not be in 1.0, and which we'll ask developers not to focus on. We need to trim down to hit dates, after all.
Must-have features
DONE: newforms-admin.
It's clear from discussion on this list that most consider a release without newforms-admin to be a bad idea. (Committed in [7967].)
Replacement of oldforms throughout Django.
Nothing in Django 1.0 should rely on the deprecated oldforms package. We'll need to replace oldforms usage in generic views, and in django.contrib.auth.
django.contrib.comments still uses oldforms as well, but is a bit of a special case.
DONE: Making Django 100% WSGI compliant.
This simply involves fixing ticket #285. We've delayed doing this to avoid the backwards-incompatible change, but we must make this change before 1.0. (Committed in [8015].)
"Maybe" features
Again, these are features that should be in 1.0. In most cases, they're actively being worked on by members of the development community and simply need focus by committers (more about how that process will work below).
These features are arranged in rough order of importance.
- Signal performance improvements (#6814).
- DONE: Large file uploads (#2070). (Committed in [7814].)
- INSTALLED_APPS refactoring (i.e. app() objects) (#3591).
- File storage refactoring (#5361 and more).
- Model-level validation (#6845).
- Full GenericForeignKey support in newforms-admin (#4667).
- Land GeoDjango as django.contrib.gis.
- Many-to-many intermediates (#6095).
- Fix all known bugs preventing Django from running on alternate Python implementations. In practice this means fixing any bugs filed before 1.0 beta from people working on running Django on an alternate VM.
- De-cruftify custom template tag loading (including removing custom template tag __path__ hacking) (#6587, etc.).
- Better support for controlling middleware ordering (#730, #749).
- Syntax for self-referencing fields in queries (#7210).
- Finish documentation refactoring.
Features not in 1.0
Unfortunately, the only way to get this done is to say no a lot. Let's start now:
Aggregation support. Although this is a Summer of Code project that's looking very promising, the timeline for SoC won't fit with the aggressive schedule we're setting for 1.0. Further, it's a "dangerous" change in that it modifies parts of Django's query engine, and that needs to be rock-solid for a 1.0 release.
The good news is that it'll make a kick-ass 1.1 feature!
Any other additions to django.contrib. Though there are many nice candidates out there, we simply don't have time to roll them into Django in time for a release. We'll come up with a "contrib process" post-1.0 and start looking at this then.
Any additional database backends. Again, the overhead in integrating a new database backend is too much. These will need to remain external backends until after 1.0.
Any features not on this list.
We want to ship bug-free, so we'll dedicate as much of our time to bug stomping as possible. This means that feature requests will need to be deferred.
Schedule
Django 1.0 will be released in early September.
The general release process will be:
An alpha release containing all must-have features, but likely not bug-free. We'll push hard to have all the must-haves done in time for ample testing.
The alpha release will also promote any "pending deprecation" warnings to full-blown deprecation warnings.
Two beta releases.
All "maybe" features must be completed by the first beta; after that, Django will enter feature freeze for about a month while we kill bugs.
At least one -- and hopefully only one -- release candidate. The candidate release will mark a total freeze (as well as a string freeze for translators); only outright bug fixes will be accepted past this point.
A final release.
A big-ass party.
We will hold development sprints in between each release to focus on the next release.
All the releases until 1.0 will be "snapshot" releases: we won't be backporting fixes -- even security fixes -- but will just be fixing bugs in the next release.
Dates
For details on the 1.0 sprints, see the wiki:Sprints page.
| July 10-12 | newforms-admin sprint in person at EuroPython and around the world in IRC. |
| July 18 | Push to 1.0 alpha sprint in Sausalito, CA, and in IRC. |
| July 20 | 1.0 alpha. |
| August 1 | Push to beta sprint in Washington, DC and in IRC. |
| August 5 | 1.0 beta 1. |
| August 8 | Push to beta 2 sprint in Lawrence, KS. |
| August 12 | 1.0 beta 2. |
| August 15 | Release candidate sprint in Austin, TX. |
| August 19 | 1.0 rc 1. |
| August 22 | Final release sprint in Portland, OR |
| August 26 | Earliest possible 1.0 release date, or perhaps rc2. |
| September 2 | 1.0 |
Process
Each feature on the list (both "must-have" and "maybe") will have a "lieutenant" (to steal of term from the Linux community) and a committer assigned. It's OK if this is the same person, but the idea is that one committer can keep an eye and commit from patches from a number of trusted lieutenants. In most cases, the features on the todo list have obvious lieutenants; we'll need to assign missing ones and also committers. See VersionOneFeatures for the current list of lieutenants and committers.
James, 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.
Once 1.0 is out we'll appoint a "version manager". This person will be responsible for maintaining the 1.0 release series, which means backporting security fixes and "important" bugs and releasing 1.0.1, etc.
Similarly, we'll appoint a 0.96 version manger who will do the same with 0.96. We'll continue to support 0.96 until 1.1 ships.
With the 1.0 release, however, we will stop support 0.95 and earlier. This is somewhat flexible; if someone has a stake in one of those older versions we'll happily let them continue to maintain those releases, but if nobody steps up the core team won't be able to do it.
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.
This guide 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.
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!
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.0 features, you should expect that your patch won't get checked in until after 1.0.
Attend a sprint (in person or in IRC).
We'll have about a half dozen sprints between now and the final 1.0 release. Lots of work gets done at sprints, and there's usually someone around willing to help new developers get started.
Organize tickets.
- Must-have feature bugs go in the "1.0 alpha" milestone. These basically should be all nfa-blocker tickets. Bugs in the must-have features are not to be part of this milestone; they can be fixed after the alpha and should be put in the "1.0" milestone.
- Any feature tickets related to the maybe list get put in the "1.0 beta" milestone.
- Any remaining bugs go in the "1.0" 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!
Notes and miscellany
On comments
django.contrib.comments is a bit of special case. Ideally, Django 1.0 will ship with no core use of oldforms. However, refactoring the entire comment system -- not just replacing forms -- is overdue, and is the subject of a Google Summer of Code project. So it would be silly to simply replace the form use when the whole package is scheduled to be replaced.
August 11 is the suggested pencils down date for GSoC. This means that if Thejaswi (the student working on comments for GSoC) is on track, he will be completed around the time of the beta 2 freeze date. July 14 is the midterm evaluation date for Summer of Code; we should be able to get a good idea then whether completion on schedule is likely.
If the midterm evaluation says that the project is going badly, we'll abandon ship and simply replace the form components in the current contrib.comments with newforms; we'll ship the new comment library in a future release.
If the midterm evaluation is positive -- which is highly likely -- we'll work on the assumption that the new comment framework will be merged intro trunk before the beta 2 release (and possible earlier, if Thejaswi has something ready). We'll encourage people to push the new framework pretty hard, especially during sprints.
If we get to August 11 and we don't have a release candidate, we can simply release with oldforms comments: it'll be annoying but not a deal-breaker.
On file storage
In addition to the primary ticket, the patch implementing file storage improvements also rolls in fixes to several other tickets. All of these tickets are tagged with a keyword of fs-rf-fixed, and should be referenced as fixed in the commit message when the patch is committed to trunk.
Another goal of this patch is to open up additional possibilities for more granular handling of things like file and directory names, among others. There are also several tickets requesting these features, and though these requests won't be directly resolved, the patch will allow them to added on a per-site or even per-app basis. As such, these tickets are tagged with fs-rf-docs, indicating that the documentation included with the patch will explain how these features can be added outside of core.