Version 28 (modified by anonymous, 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
      :trac:`VersionOneFeatures` page.
    
__ `dates`_

.. contents:: Table of Contents

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

1. **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 :trac:`[7967]`.)
   
2. 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`__.
   
3. **DONE:** Making Django 100% WSGI compliant.

   This simply involves fixing ticket :trac:`#285`. We've delayed doing
   this to avoid the backwards-incompatible change, but we must make this change
   before 1.0. (Committed in :trac:`[8015]`.)

__ `on comments`_

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

1. **DONE:** Signal performance improvements (:trac:`#6814`). (Committed in :trac:`[8223]`.)

2. **DONE:** Large file uploads (:trac:`#2070`). (Committed in :trac:`[7814]`.)

3. **MOVED:** (to post-1.0) ``INSTALLED_APPS`` refactoring (i.e. ``app()`` objects) (:trac:`#3591`).

4. **DONE:** File storage refactoring (:trac:`#5361` and `more`__). (Committed in :trac:`[8244]`.)

5. **MOVED:** (to post-1.0) Model-level validation (:trac:`#6845`).

6. **DONE:** Full ``GenericForeignKey`` support in newforms-admin (:trac:`#4667`). (Committed in :trac:`[8279]`.)

7. **DONE:** Land GeoDjango as ``django.contrib.gis``. (Committed in :trac:`[8219]`.)

8. **DONE:** Many-to-many intermediates (:trac:`#6095`). (Committed in :trac:`[8136]`.)

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

10. De-cruftify custom template tag loading (including removing custom template
    tag ``__path__`` hacking) (:trac:`#6587`, etc.).

11. **DONE:** Better support for controlling middleware ordering (:trac:`#730`,
    :trac:`#749`). (Scope changed, fixed for cache in :trac:`[8260]`.)
    
12. Finish documentation refactoring.

__ `on file storage`_

Features not in 1.0
-------------------


Unfortunately, the only way to get this done is to say no a lot. Let's start
now:

1. 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!
   
2. 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.
   
3. 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.
   
4. 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 :trac:`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 8        **1.0 alpha 2.**

August 8        Push to beta 2 sprint in Lawrence, KS.

August 14       **1.0 beta.**

August 15       Release candidate sprint in Austin, TX.

August 21       **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**
==============  ===============================================================

.. _EuroPython: http://code.djangoproject.com/wiki/SprintEuroPython2008

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 :trac:`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!
      
__ http://www.djangoproject.com/documentation/contributing/
__ `Must-have features`_
__ `"Maybe" features`_

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 :trac:`#5361 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.

.. _fs-rf-fixed: http://code.djangoproject.com/query?keywords=~fs-rf-fixed
.. _fs-rf-docs: http://code.djangoproject.com/query?keywords=~fs-rf-docs
Note: See TracWiki for help on using the wiki.
Back to Top