Version 2 (modified by Russell Keith-Magee, 15 years ago) ( diff )

Added link to the v1.2 features page

==================
Django 1.2 Roadmap
==================

This document will eventually detail the schedule and roadmap towards Django 1.2. For the moment, it's a placeholder.

What will be in Django 1.2?
===========================

Proposals for feature additions in Django 1.2 are now open - add your proposal `to the wiki`__ .

__ http://code.djangoproject.com/wiki/Version1.2Features

GeoDjango
---------

1.2 features for GeoDjango are being coordinated on the `wiki`__ and the `GeoDjango mailing list`__.

__ http://code.djangoproject.com/wiki/GeoDjango1.2
__ http://groups.google.com/group/geodjango

Schedule
========

Django 1.2 is beyond deadline at this point.  It will be released as soon as it is in good enough
condition to be released.  Please help contribute to resolving any issues on the 
`list of open tickets`__.

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.2; work phase ends, and any 
                      major incomplete features will be postponed.
                      
February 23, 2009     Django 1.2 alpha.

March 23, 2009        Django 1.2 beta. Feature freeze; only bug fixes will be
                      allowed after this point.

April 2, 2009         Django 1.2 rc 1. and string freeze

April 13, 2009        Django 1.2 final
====================  =========================================================

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

.. _django-developers: http://groups.google.com/group/django-developers
__ http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&milestone=1.2

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 :trac:`Version1.2Features` 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.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).
    
      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.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!
      
__ http://docs.djangoproject.com/en/dev/internals/contributing/
__ http://docs.djangoproject.com/en/dev/internals/release-process/

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