Version 15 (modified by ElliottM, 16 years ago) ( diff )

fixing a copy/paste error

Django 1.1 Roadmap

This document details the schedule and roadmap towards Django 1.1. All the details follow; here's the executive summary:

What will be in Django 1.1?

Over 60 features were proposed for Django 1.1. After discussion by the development community, these features were categorized "must have", "maybe", or "no" -- see our official release process for more information on how this works.

Remember: see Version1.1Features for more details on each feature below; these are just summaries.

Must-have features

These are the features considered critical for the 1.1 release.

  • [Admin-01] Bulk-edit on changelist pages.
  • [Admin-02] Integrate django-batchadmin.
  • [Admin-03] Make the admin use a URL resolver.
  • [Admin-08] Make filters in admin changelists persistant.
  • [Contrib-05] Message passing for anonymous users.
  • [Contrib-12] Write-through cache session backend.
  • [ORM-01] ORM aggregation.
  • [ORM-03] Model validation.
  • [ORM-06] Expression support in QuerySet.update().
  • [ORM-14] Exclude fields in a SELECT (QuerySet.defer()).
  • [Test-03] Run Django test cases inside a transaction (speed improvements).
  • [View-01] Class-based generic views.

"Maybe" features

Again, these are features that should be in 1.1. In most cases, they're actively being worked on by members of the development community and will be checked in if finished in time.

The following features have committers who'll take responsibility for getting the feature in; as such they can be considered a sort of "first-priority" of among the "maybe" features:

  • [Admin-05] ModelAdmin should allow for overriding of ForeignKey/ManyToMany options.
  • [Admin-06] Read-only form fields.
  • [Admin-07] Custom FilterSpecs.
  • [Contrib-02] Improved customizability of django.contrib.comments.
  • [Contrib-03] Integration of comment-utils.
  • [Contrib-06] Honor REMOTE_USER provided by the server.
  • [Contrib-07] Implement Atom Publishing Protocol.
  • [Contrib-11] Signed cookies.
  • [Form-01] Selectable HTML output for forms/fields.
  • [ORM-15] Day-of-week filter for date/datetime Fields.
  • DONE: [ORM-17] {% default %} clause for {% for %} loops. (Committed in [9530])
  • [ORM-19] Add support for database schemas.
  • [Template-06] Better template tag loading.
  • [Test-01] Follow redirect chains on the Test Client.
  • [Test-02] Disable all e-mail sending for debugging.
  • [View-03] Support for wsgi.file_wrapper for large files.

The following features were reviewed highly and are generally accepted as "wanted", but currently are lacking a "champion" to see the feature done. This means these features are likely to be included in 1.1 if finished, but are a sort of "second-tier":

  • [Contrib-01] Session-based form wizard.
  • [Form-02] django.forms.SafeForm - forms with built-in CSRF protection.
  • [ORM-09] Manager.update_or_create() and Model.update().
  • [ORM-10] QuerySet.select_for_update() method.
  • [ORM-11] QuerySet.cache() method.
  • [ORM-12] Allow the use of property() in fields.
  • [ORM-13] Support for DISTINCT ON queries with QuerySet.distinct().
  • [ORM-16] Native autocommit option for Postgresql backend.
  • [ORM-18] Add signals to many-to-many objects.
  • [Template-01] Extend inclusion tag syntax to allow custom templates.
  • [Template-04] Clean-up of django.template internals.
  • [Template-05] Namespace support for template libraries.

Special cases

As is to be expected, a few features don't fit so easily into any of the hard categories:

  • [ORM-05] Sharing of selected_related() data in memory, and/or an ORM identity map.

    The scope of this feature is a bit nebulous, but it's under discussion on django-developers. If consensus is reached and the feature can be implemented in time, it'll get into 1.1.

  • [Form-01] Selectable HTML output for forms/fields.

    This feature is similarly not fully-scoped, though this one has a reference implementation so it's further along. However,, there's a fair bit of controversy about the particular proposed implementation. Again, consensus is the issue here; discussion is ongoing.

  • [View-02] Add RequestContext by default in render_to_response.

    This proposal is strongly controversial, with multiple +1 and -1 votes. As such, consensus seems unlikely; a middle-ground approach will need be found, which likely pushes this out of scope for 1.1.

Rejected/deferred features

The remaining proposed features were rejected or deferred for a variety of reasons; see Version1.1Features for a complete list of these rejected features and reasons for rejection or deferral.

Schedule

Django 1.1 will be released the week of March 16th, 2009.

The complete schedule follows. Note that dates are plus or minus a couple of days as needed:

January 15, 2009 "Major" feature freeze for 1.1; work phase ends, and any major incomplete features will be postponed.
January 20, 2009 Django 1.1 alpha.
February 15, 2009 Feature freeze; only bug fixes will be allowed after this point.
February 20, 2009 Django 1.1 beta.
March 10, 2009 String freeze
March 12, 2009 Django 1.1 rc 1.
March 16-20, 2009 Django 1.1 final

We'll hold a series of Sprints to work on 1.1 starting in late December; stay tuned to the Sprints page and/or the django-developers mailing list for details.

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.1Features 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.1 features, you should expect that your patch won't get checked in until after 1.1.

    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).

    We'll have four or five sprints between now and March. Lots of work gets done at sprints, and there's usually someone around willing to help new developers get started.

  • Organize tickets.

    • Feature tickets should go in the "1.1 alpha" or "1.1 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.1; those should be in the "1.1" 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!

Note: See TracWiki for help on using the wiki.
Back to Top