Changes between Version 1 and Version 2 of Version1.2Roadmap

07/29/2009 03:06:50 AM (10 years ago)
Russell Keith-Magee

Added link to the v1.2 features page


  • Version1.2Roadmap

    v1 v2  
    88This document will eventually detail the schedule and roadmap towards Django 1.2. For the moment, it's a placeholder.
     10What will be in Django 1.2?
     13Proposals for feature additions in Django 1.2 are now open - add your proposal `to the wiki`__ .
     201.2 features for GeoDjango are being coordinated on the `wiki`__ and the `GeoDjango mailing list`__.
     28Django 1.2 is beyond deadline at this point.  It will be released as soon as it is in good enough
     29condition to be released.  Please help contribute to resolving any issues on the
     30`list of open tickets`__.
     32The complete schedule follows. Note that dates are plus or minus a couple of
     33days as needed:
     35====================  =========================================================
     36January 15, 2009      "Major" feature freeze for 1.2; work phase ends, and any
     37                      major incomplete features will be postponed.
     39February 23, 2009     Django 1.2 alpha.
     41March 23, 2009        Django 1.2 beta. Feature freeze; only bug fixes will be
     42                      allowed after this point.
     44April 2, 2009         Django 1.2 rc 1. and string freeze
     46April 13, 2009        Django 1.2 final
     47====================  =========================================================
     49We'll hold a series of :trac:`Sprints` to work on 1.2 starting in late
     50December; stay tuned to the :trac:`Sprints` page and/or the
     51`django-developers`_ mailing list for details.
     53.. _django-developers:
     59Each feature on the list (both "must-have" and "maybe") will have a
     60"lieutenant" (a term stolen from the Linux community) and a committer
     61assigned. It's OK if this is the same person, but it's better if not: one
     62committer can keep an eye and commit from patches from a number of trusted
     63lieutenants. See :trac:`Version1.2Features` for the current list of
     64lieutenants and committers.
     66James Bennett, as the release manager, will be in charge of keeping the
     67schedule. He'll keep track of who's working on what issues so that bug reports
     68can be efficiently routed; he'll also nag, cajole and (if necessary) berate
     69developers who are in danger of missing deadlines.
     71How you can help
     74The only way we'll meet this deadline is with a great deal of community effort.
     75To that end, here's how you can help:
     77    * Read the `guide to contributing to Django`__ and the `guide to Django's
     78      release process`__.
     80      These guides explains how our process works. where to ask questions,
     81      etc. It'll save everyone time if we're all on the same page when it
     82      comes to process.
     84    * Work on features from the list above.
     88      The joy of Open Source is that nobody gets to tell you what to do; you
     89      can scratch whichever itch you like. However, if you work on items *not*
     90      on the list of 1.2 features, you should expect that your patch won't get
     91      checked in until after 1.2.
     93      Get in touch with the lieutenant/committer for the feature you'd like
     94      to work on and help out. Or just find open tickets and start submitting
     95      patches!
     97    * Attend a sprint (in person or in IRC).
     99      We'll have four or five sprints between now and March. Lots of work gets
     100      done at sprints, and there's usually someone around willing to help new
     101      developers get started.
     103    * Organize tickets.
     105       * Feature tickets should go in the "1.2 alpha" or "1.2 beta" milestone.
     107         Which one? Well, major changes must be made before the alpha, and
     108         minor feature changes before the beta. So "major" feature additions
     109         go in the alpha milestone, and minor additions in the beta one. If
     110         you're not sure, then the feature is minor.
     112         **Bugs** are **not** to be part of these milestone; any bug is a
     113         candidate for fixing and should be left un-milestoned. The exception
     114         is bugs in features added for 1.2; those should be in the "1.2"
     115         milestone.
     117    * Test the release snapshots (alphas, betas) against your code and report
     118      bugs.
     120      We need *lots* of testers if we're to have a bug-free release. Download
     121      a snapshot or an SVN checkout and give it a try!
Back to Top