Version 9 (modified by Bryan Veloso, 14 years ago) ( diff )

New feature freeze date (from JB/django-dev).

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

This document details the schedule and roadmap towards Django
1.2. Django 1.2 is scheduled for release on March 9, 2010.

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

Whatever gets committed by January 5th!

Django 1.2 will be a fully time-based release; any features completed and checked in by the feature freeze deadline (January 5th) will be included. Any that miss the deadline won't.
The Django core team has prepared a list of `prioritized features for 1.2`__ to help direct our development resources, but the list is more of a guideline than a hard and fast
feature list.

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

Major milestones along the way to 1.2 are scheduled below. See `Process`_,
below, for more details.

==================  ===========================================================
October 20, 2009    Voting on proposals ends. Priority list for 1.2 features
                    announced shortly thereafter.

November 30, 2009   Progress assessment; final 1.2 feature list.

January 5, 2010   Django 1.2 alpha; major feature freeze.

January 26, 2010    Django 1.2 beta; complete feature freeze.

March 2, 2010       Django 1.2 RC 1; translation string freeze.

March 9, 2010       Django 1.2 final (or RC 2, if needed).
==================  ===========================================================

Process
=======

We've tweaked the process slightly since Django 1.1 to try to avoid schedule
slippage. If you helped out with 1.1 most of the following should be relatively
similar; the major difference is the dropping of the idea of "must-have"
features. The purpose of feature triage, this time around, will simply be to
help people focus work on highly-desired areas; any code not complete by feature
freeze dates simply won't make it into 1.2.

Proposal voting
---------------

The voting phase needs to achieve two things:

* Design Decision Needed (DDN) triage work on proposed tickets. This is the
  +1/+0/-0/-1 vote. These votes mean:
   
        * +1 - Love the idea, want want
        * +0 - Ok with the idea, but wouldn't mind if it doesn't happen
        * -0 - Not really in favor but won't stand in the way of it
        * -1 - Hell no.
        
* Nominating tickets that someone is personally willing to commit to.

In the up/down voting, we're trying to do pure DDN work. +1 doesn't mean "I'd
like this in v1.2", it means "I like this idea and I'd like it in Django". It
doesn't include any estimation of the likelihood that the patch will be finished
(e.g., Simon's logging proposal). If you think a feature should be in v1.2, you
need to commit to working on it. There's no way to vote against an idea *for
v1.2* - you are either against an idea completely, or for it but not willing to
work on it yourself for v1.2.

Certain features may be not-well-enough-specified for a complete vote. That's
okay; we'll also allow an "abstain/defer" vote, which basically means "I don't
have enough information to vote for or against this proposal yet." Features in
that category will simply stay "design decision needed" until there's enough
information to make a call.

Once voting is complete, we collate (and possibly massage) the results, modify
tickets to reflect the accepted/rejected status, and we announce the feature
list using the following categories:

* High Priority: A core developer is actively engaged in the ticket.
 
* Medium Priority: A core developer is interested in the ticket, but requires
  someone to do the work.

* Low priority: No core developer has declared a specific interest, but if a
  good implementation appears, that may change.

The voting process plus the use of "High Priority" rather than "Must have" aims
to reflect the reality of Django development. Any finished code will be
committed, regardless of schedule. If a feature still needs some design work,
that's fine - as long as the work is done by the feature freeze.

For a feature to make "high" or "medium" priority, a feature needs to have a
"lieutenant" (a term stolen from the Linux community) and a committer
associated. 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. We'll keep track of who these folks are over at :trac:`Version1.2Features`.

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.

Progress assessment
-------------------

Around the end of November, we will take a look at progress and make a call on
which high-priority items are likely to make the cut. This is the date at which
finalize the v1.2 feature list, and we work out whether we need to adjust our
deadlines.

If we decide to slip the schedule, this is when that decision will be made. If
we decide to stick with the original schedule, we'll commit to dropping features
to hit the deadlines.

Feature freeze / Alpha 1
------------------------

As with v1.1, all major features must be committed by the Alpha 1 deadline. Any
work not done by this point will be deferred or dropped.

Beta 1
------

As with v1.1, Beta 1 marks the end of *any* feature work. Only bug fixes will be
allowed in after this point.

RC 1
----

Again, no change here. RC 1 will, Murphy willing, be a true release candidate:
1.2 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.

Release
-------
Django 1.2 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:

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