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

07/29/09 01:06:50 (5 years ago)

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!