| | 26 | Schedule |
| | 27 | ======== |
| | 28 | |
| | 29 | Major milestones along the way to 1.2 are scheduled below. See `Process`_, |
| | 30 | below, for more details. |
| | 31 | |
| | 32 | ================== =========================================================== |
| | 33 | October 20, 2009 Voting on proposals ends. Priority list for 1.2 features |
| | 34 | announced shortly thereafter. |
| | 35 | |
| | 36 | November 30, 2009 Progress assessment; final 1.2 feature list. |
| | 37 | |
| | 38 | December 22, 2009 Django 1.2 alpha; major feature freeze. |
| | 39 | |
| | 40 | January 26, 2010 Django 1.2 beta; complete feature freeze. |
| | 41 | |
| | 42 | March 2, 2010 Django 1.2 RC 1; translation string freeze. |
| | 43 | |
| | 44 | March 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 |
| | 50 | We've tweaked the process slightly since Django 1.1 to try to avoid schedule |
| | 51 | slippage. If you helped out with 1.1 most of the following should be relatively |
| | 52 | similar; the major difference is the dropping of the idea of "must-have" |
| | 53 | features. The purpose of feature triage, this time around, will simply be to |
| | 54 | help people focus work on highly-desired areas; any code not complete by feature |
| | 55 | freeze dates simply won't make it into 1.2. |
| | 56 | |
| | 57 | Proposal voting |
| | 58 | --------------- |
| | 59 | |
| | 60 | The voting phase needs to achieve two things: |
| | 61 | |
| | 62 | * Design Decision Needed (DDN) triage work on proposed tickets. This is the |
| | 63 | +1/+0/-0/-1 vote. These votes mean: |
| | 64 | |
| | 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. |
| | 69 | |
| | 70 | * Nominating tickets that someone is personally willing to commit to. |
| | 71 | |
| | 72 | In the up/down voting, we're trying to do pure DDN work. +1 doesn't mean "I'd |
| | 73 | like this in v1.2", it means "I like this idea and I'd like it in Django". It |
| | 74 | doesn'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 |
| | 76 | need to commit to working on it. There's no way to vote against an idea *for |
| | 77 | v1.2* - you are either against an idea completely, or for it but not willing to |
| | 78 | work on it yourself for v1.2. |
| | 79 | |
| | 80 | Once voting is complete, we collate (and possibly massage) the results, modify |
| | 81 | tickets to reflect the accepted/rejected status, and we announce the feature |
| | 82 | list using the following categories: |
| | 83 | |
| | 84 | * High Priority: A core developer is actively engaged in the ticket. |
| | 85 | |
| | 86 | * Medium Priority: A core developer is interested in the ticket, but requires |
| | 87 | someone to do the work. |
| | 88 | |
| | 89 | * Low priority: No core developer has declared a specific interest, but if a |
| | 90 | good implementation appears, that may change. |
| | 91 | |
| | 92 | The voting process plus the use of "High Priority" rather than "Must have" aims |
| | 93 | to reflect the reality of Django development. Any finished code will be |
| | 94 | committed, regardless of schedule. If a feature still needs some design work, |
| | 95 | that's fine - as long as the work is done by the feature freeze. |
| | 96 | |
| | 97 | For a feature to make "high" or "medium" priority, a feature needs to have a |
| | 107 | |
| | 108 | Progress assessment |
| | 109 | ------------------- |
| | 110 | |
| | 111 | Around the end of November, we will take a look at progress and make a call on |
| | 112 | which high-priority items are likely to make the cut. This is the date at which |
| | 113 | finalize the v1.2 feature list, and we work out whether we need to adjust our |
| | 114 | deadlines. |
| | 115 | |
| | 116 | If we decide to slip the schedule, this is when that decision will be made. If |
| | 117 | we decide to stick with the original schedule, we'll commit to dropping features |
| | 118 | to hit the deadlines. |
| | 119 | |
| | 120 | Feature freeze / Alpha 1 |
| | 121 | ------------------------ |
| | 122 | |
| | 123 | As with v1.1, all major features must be committed by the Alpha 1 deadline. Any |
| | 124 | work not done by this point will be deferred or dropped. |
| | 125 | |
| | 126 | Beta 1 |
| | 127 | ------ |
| | 128 | |
| | 129 | As with v1.1, Beta 1 marks the end of *any* feature work. Only bug fixes will be |
| | 130 | allowed in after this point. |
| | 131 | |
| | 132 | RC 1 |
| | 133 | ---- |
| | 134 | |
| | 135 | Again, no change here. RC 1 will, Murphy willing, be a true release candidate: |
| | 136 | 1.2 final should be identical to RC 1. RC 1 also marks string freeze; |
| | 137 | translators will have roughly a week to submit updated translations for |
| | 138 | inclusion in the final release. |
| | 139 | |
| | 140 | Release |
| | 141 | ------- |
| | 142 | Django 1.2 final will ship one week after the last RC. Hopefully we'll only need |
| | 143 | a single RC, so, the final release will follow roughly a week after RC 1. If |
| | 144 | blockers are found, another RC will be released instead. |