| 10 | What will be in Django 1.2? |
| 11 | =========================== |
| 12 | |
| 13 | Proposals for feature additions in Django 1.2 are now open - add your proposal `to the wiki`__ . |
| 14 | |
| 15 | __ http://code.djangoproject.com/wiki/Version1.2Features |
| 16 | |
| 17 | GeoDjango |
| 18 | --------- |
| 19 | |
| 20 | 1.2 features for GeoDjango are being coordinated on the `wiki`__ and the `GeoDjango mailing list`__. |
| 21 | |
| 22 | __ http://code.djangoproject.com/wiki/GeoDjango1.2 |
| 23 | __ http://groups.google.com/group/geodjango |
| 24 | |
| 25 | Schedule |
| 26 | ======== |
| 27 | |
| 28 | Django 1.2 is beyond deadline at this point. It will be released as soon as it is in good enough |
| 29 | condition to be released. Please help contribute to resolving any issues on the |
| 30 | `list of open tickets`__. |
| 31 | |
| 32 | The complete schedule follows. Note that dates are plus or minus a couple of |
| 33 | days as needed: |
| 34 | |
| 35 | ==================== ========================================================= |
| 36 | January 15, 2009 "Major" feature freeze for 1.2; work phase ends, and any |
| 37 | major incomplete features will be postponed. |
| 38 | |
| 39 | February 23, 2009 Django 1.2 alpha. |
| 40 | |
| 41 | March 23, 2009 Django 1.2 beta. Feature freeze; only bug fixes will be |
| 42 | allowed after this point. |
| 43 | |
| 44 | April 2, 2009 Django 1.2 rc 1. and string freeze |
| 45 | |
| 46 | April 13, 2009 Django 1.2 final |
| 47 | ==================== ========================================================= |
| 48 | |
| 49 | We'll hold a series of :trac:`Sprints` to work on 1.2 starting in late |
| 50 | December; stay tuned to the :trac:`Sprints` page and/or the |
| 51 | `django-developers`_ mailing list for details. |
| 52 | |
| 53 | .. _django-developers: http://groups.google.com/group/django-developers |
| 54 | __ http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&milestone=1.2 |
| 55 | |
| 56 | Process |
| 57 | ======= |
| 58 | |
| 59 | Each feature on the list (both "must-have" and "maybe") will have a |
| 60 | "lieutenant" (a term stolen from the Linux community) and a committer |
| 61 | assigned. It's OK if this is the same person, but it's better if not: one |
| 62 | committer can keep an eye and commit from patches from a number of trusted |
| 63 | lieutenants. See :trac:`Version1.2Features` for the current list of |
| 64 | lieutenants and committers. |
| 65 | |
| 66 | James Bennett, as the release manager, will be in charge of keeping the |
| 67 | schedule. He'll keep track of who's working on what issues so that bug reports |
| 68 | can be efficiently routed; he'll also nag, cajole and (if necessary) berate |
| 69 | developers who are in danger of missing deadlines. |
| 70 | |
| 71 | How you can help |
| 72 | ---------------- |
| 73 | |
| 74 | The only way we'll meet this deadline is with a great deal of community effort. |
| 75 | To that end, here's how you can help: |
| 76 | |
| 77 | * Read the `guide to contributing to Django`__ and the `guide to Django's |
| 78 | release process`__. |
| 79 | |
| 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. |
| 83 | |
| 84 | * Work on features from the list above. |
| 85 | |
| 86 | |
| 87 | |
| 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. |
| 92 | |
| 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! |
| 96 | |
| 97 | * Attend a sprint (in person or in IRC). |
| 98 | |
| 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. |
| 102 | |
| 103 | * Organize tickets. |
| 104 | |
| 105 | * Feature tickets should go in the "1.2 alpha" or "1.2 beta" milestone. |
| 106 | |
| 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. |
| 111 | |
| 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. |
| 116 | |
| 117 | * Test the release snapshots (alphas, betas) against your code and report |
| 118 | bugs. |
| 119 | |
| 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! |
| 122 | |
| 123 | __ http://docs.djangoproject.com/en/dev/internals/contributing/ |
| 124 | __ http://docs.djangoproject.com/en/dev/internals/release-process/ |
| 125 | |