Changes between Version 5 and Version 6 of Version1.2Roadmap

10/08/2009 12:27:01 PM (11 years ago)

Added 1.2 roadmap


  • Version1.2Roadmap

    v5 v6  
    8 This document will eventually detail the schedule and roadmap towards Django 1.2. The exact schedule hasn't been formally decided, but a planned release cycle of 6-9 months should be expected.
     8This document details the schedule and roadmap towards Django
     91.2. Django 1.2 is scheduled for release on March 9, 2010.
    1011What will be in Django 1.2?
    13 Proposals for feature additions in Django 1.2 are now open - add your proposal `to the wiki`__ .
     14Proposals for feature additions in Django 1.2 are now open - add your proposal `to the wiki`__.
     29Major milestones along the way to 1.2 are scheduled below. See `Process`_,
     30below, for more details.
     32==================  ===========================================================
     33October 20, 2009    Voting on proposals ends. Priority list for 1.2 features
     34                    announced shortly thereafter.
     36November 30, 2009   Progress assessment; final 1.2 feature list.
     38December 22, 2009   Django 1.2 alpha; major feature freeze.
     40January 26, 2010    Django 1.2 beta; complete feature freeze.
     42March 2, 2010       Django 1.2 RC 1; translation string freeze.
     44March 9, 2010       Django 1.2 final (or RC 2, if needed).
     45==================  ===========================================================
    29 Each feature on the list (both "must-have" and "maybe") will have a
     50We've tweaked the process slightly since Django 1.1 to try to avoid schedule
     51slippage. If you helped out with 1.1 most of the following should be relatively
     52similar; the major difference is the dropping of the idea of "must-have"
     53features. The purpose of feature triage, this time around, will simply be to
     54help people focus work on highly-desired areas; any code not complete by feature
     55freeze dates simply won't make it into 1.2.
     57Proposal voting
     60The voting phase needs to achieve two things:
     62* Design Decision Needed (DDN) triage work on proposed tickets. This is the
     63  +1/+0/-0/-1 vote. These votes mean:
     65        * +1 - Love the idea, want want
     66        * +0 - Ok with the idea, but wouldn't mind if it doesn't happen
     67        * -0 - Not really in favor but won't stand in the way of it
     68        * -1 - Hell no.
     70* Nominating tickets that someone is personally willing to commit to.
     72In the up/down voting, we're trying to do pure DDN work. +1 doesn't mean "I'd
     73like this in v1.2", it means "I like this idea and I'd like it in Django". It
     74doesn't include any estimation of the likelihood that the patch will be finished
     75(e.g., Simon's logging proposal). If you think a feature should be in v1.2, you
     76need to commit to working on it. There's no way to vote against an idea *for
     77v1.2* - you are either against an idea completely, or for it but not willing to
     78work on it yourself for v1.2.
     80Once voting is complete, we collate (and possibly massage) the results, modify
     81tickets to reflect the accepted/rejected status, and we announce the feature
     82list using the following categories:
     84* High Priority: A core developer is actively engaged in the ticket.
     86* Medium Priority: A core developer is interested in the ticket, but requires
     87  someone to do the work.
     89* Low priority: No core developer has declared a specific interest, but if a
     90  good implementation appears, that may change.
     92The voting process plus the use of "High Priority" rather than "Must have" aims
     93to reflect the reality of Django development. Any finished code will be
     94committed, regardless of schedule. If a feature still needs some design work,
     95that's fine - as long as the work is done by the feature freeze.
     97For a feature to make "high" or "medium" priority, a feature needs to have a
    3098"lieutenant" (a term stolen from the Linux community) and a committer
    31 assigned. It's OK if this is the same person, but it's better if not: one
     99associated. It's OK if this is the same person, but it's better if not: one
    32100committer can keep an eye and commit from patches from a number of trusted
    33 lieutenants. See :trac:`Version1.2Features` for the current list of
    34 lieutenants and committers.
     101lieutenants. We'll keep track of who these folks are over at :trac:`Version1.2Features`.
    36103James Bennett, as the release manager, will be in charge of keeping the
    38105can be efficiently routed; he'll also nag, cajole and (if necessary) berate
    39106developers who are in danger of missing deadlines.
     108Progress assessment
     111Around the end of November, we will take a look at progress and make a call on
     112which high-priority items are likely to make the cut. This is the date at which
     113finalize the v1.2 feature list, and we work out whether we need to adjust our
     116If we decide to slip the schedule, this is when that decision will be made. If
     117we decide to stick with the original schedule, we'll commit to dropping features
     118to hit the deadlines.
     120Feature freeze / Alpha 1
     123As with v1.1, all major features must be committed by the Alpha 1 deadline. Any
     124work not done by this point will be deferred or dropped.
     126Beta 1
     129As with v1.1, Beta 1 marks the end of *any* feature work. Only bug fixes will be
     130allowed in after this point.
     132RC 1
     135Again, no change here. RC 1 will, Murphy willing, be a true release candidate:
     1361.2 final should be identical to RC 1. RC 1 also marks string freeze;
     137translators will have roughly a week to submit updated translations for
     138inclusion in the final release.
     142Django 1.2 final will ship one week after the last RC. Hopefully we'll only need
     143a single RC, so, the final release will follow roughly a week after RC 1. If
     144blockers are found, another RC will be released instead.
    41146How you can help
    54159    * Work on features from the list above.
    58161      The joy of Open Source is that nobody gets to tell you what to do; you
Back to Top