|
1 ======================== |
|
2 Django's release process |
|
3 ======================== |
|
4 |
|
5 .. _official-releases: |
|
6 |
|
7 Official releases |
|
8 ================= |
|
9 |
|
10 Django's release numbering works as follows: |
|
11 |
|
12 * Versions are numbered in the form ``A.B`` or ``A.B.C``. |
|
13 |
|
14 * ``A`` is the *major version* number, which is only incremented for major |
|
15 changes to Django, and these changes are not necessarily |
|
16 backwards-compatible. That is, code you wrote for Django 6.0 may break |
|
17 when we release Django 7.0. |
|
18 |
|
19 * ``B`` is the *minor version* number, which is incremented for large yet |
|
20 backwards compatible changes. Code written for Django 6.4 will continue |
|
21 to work under Django 6.5. |
|
22 |
|
23 * ``C`` is the *micro version* number which, is incremented for bug and |
|
24 security fixes. A new micro-release will always be 100% |
|
25 backwards-compatible with the previous micro-release. |
|
26 |
|
27 * In some cases, we'll make alpha, beta, or release candidate releases. |
|
28 These are of the form ``A.B alpha/beta/rc N``, which means the ``Nth`` |
|
29 alpha/beta/release candidate of version ``A.B``. |
|
30 |
|
31 An exception to this version numbering scheme is the pre-1.0 Django code. |
|
32 There's no guarantee of backwards-compatibility until the 1.0 release. |
|
33 |
|
34 In Subversion, each Django release will be tagged under ``tags/releases``. If |
|
35 it's necessary to release a bug fix release or a security release that doesn't |
|
36 come from the trunk, we'll copy that tag to ``branches/releases`` to make the |
|
37 bug fix release. |
|
38 |
|
39 Major releases |
|
40 -------------- |
|
41 |
|
42 Major releases (1.0, 2.0, etc.) will happen very infrequently (think "years", |
|
43 not "months"), and will probably represent major, sweeping changes to Django. |
|
44 |
|
45 Minor releases |
|
46 -------------- |
|
47 |
|
48 Minor release (1.1, 1.2, etc.) will happen roughly every nine months -- see |
|
49 `release process`_, below for details. |
|
50 |
|
51 .. _internal-release-deprecation-policy: |
|
52 |
|
53 These releases will contain new features, improvements to existing features, and |
|
54 such. A minor release may deprecate certain features from previous releases. If a |
|
55 feature in version ``A.B`` is deprecated, it will continue to work in version |
|
56 ``A.B+1``. In version ``A.B+2``, use of the feature will raise a |
|
57 ``DeprecationWarning`` but will continue to work. Version ``A.B+3`` will |
|
58 remove the feature entirely. |
|
59 |
|
60 So, for example, if we decided to remove a function that existed in Django 1.0: |
|
61 |
|
62 * Django 1.1 will contain a backwards-compatible replica of the function |
|
63 which will raise a ``PendingDeprecationWarning``. This warning is silent |
|
64 by default; you need to explicitly turn on display of these warnings. |
|
65 |
|
66 * Django 1.2 will contain the backwards-compatible replica, but the warning |
|
67 will be promoted to a full-fledged ``DeprecationWarning``. This warning is |
|
68 *loud* by default, and will likely be quite annoying. |
|
69 |
|
70 * Django 1.3 will remove the feature outright. |
|
71 |
|
72 Micro releases |
|
73 -------------- |
|
74 |
|
75 Micro releases (1.0.1, 1.0.2, 1.1.1, etc.) will be issued at least once half-way |
|
76 between minor releases, and probably more often as needed. |
|
77 |
|
78 These releases will always be 100% compatible with the associated minor release |
|
79 -- the answer to "should I upgrade to the latest micro release?" will always be |
|
80 "yes." |
|
81 |
|
82 Each minor release of Django will have a "release maintainer" appointed. This |
|
83 person will be responsible for making sure that bug fixes are applied to both |
|
84 trunk and the maintained micro-release branch. This person will also work with |
|
85 the release manager to decide when to release the micro releases. |
|
86 |
|
87 Supported versions |
|
88 ================== |
|
89 |
|
90 At any moment in time, Django's developer team will support a set of releases to |
|
91 varying levels: |
|
92 |
|
93 * The current development trunk will get new features and bug fixes |
|
94 requiring major refactoring. |
|
95 |
|
96 * All bug fixes applied to the trunk will also be applied to the last |
|
97 minor release, to be released as the next micro release. |
|
98 |
|
99 * Security fixes will be applied to the current trunk and the previous two |
|
100 minor releases. |
|
101 |
|
102 As a concrete example, consider a moment in time halfway between the release of |
|
103 Django 1.3 and 1.4. At this point in time: |
|
104 |
|
105 * Features will be added to development trunk, to be released as Django 1.4. |
|
106 |
|
107 * Bug fixes will be applied to a ``1.3.X`` branch, and released as 1.3.1, |
|
108 1.3.2, etc. |
|
109 |
|
110 * Security releases will be applied to trunk, a ``1.3.X`` branch and a |
|
111 ``1.2.X`` branch. Security fixes will trigger the release of ``1.3.1``, |
|
112 ``1.2.1``, etc. |
|
113 |
|
114 .. _release-process: |
|
115 |
|
116 Release process |
|
117 =============== |
|
118 |
|
119 Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.) |
|
120 releases every nine months, or more, depending on features. |
|
121 |
|
122 After each previous release (and after a suitable cooling-off period of a week |
|
123 or two), the core development team will examine the landscape and announce a |
|
124 timeline for the next release. Most releases will be scheduled in the 6-9 month |
|
125 range, but if we have bigger features to development we might schedule a longer |
|
126 period to allow for more ambitious work. |
|
127 |
|
128 Release cycle |
|
129 ------------- |
|
130 |
|
131 Each release cycle will be split into three periods, each lasting roughly |
|
132 one-third of the cycle: |
|
133 |
|
134 Phase one: feature proposal |
|
135 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
136 |
|
137 The first phase of the release process will be devoted to figuring out what |
|
138 features to include in the next version. This should include a good deal of |
|
139 preliminary work on those features -- working code trumps grand design. |
|
140 |
|
141 At the end of part one, the core developers will propose a feature list for the |
|
142 upcoming release. This will be broken into: |
|
143 |
|
144 * "Must-have": critical features that will delay the release if not finished |
|
145 * "Maybe" features: that will be pushed to the next release if not finished |
|
146 * "Not going to happen": features explicitly deferred to a later release. |
|
147 |
|
148 Anything that hasn't got at least some work done by the end of the first third |
|
149 isn't eligible for the next release; a design alone isn't sufficient. |
|
150 |
|
151 Phase two: development |
|
152 ~~~~~~~~~~~~~~~~~~~~~~ |
|
153 |
|
154 The second third of the release schedule is the "heads-down" working period. |
|
155 Using the roadmap produced at the end of phase one, we'll all work very hard to |
|
156 get everything on it done. |
|
157 |
|
158 Longer release schedules will likely spend more than a third of the time in this |
|
159 phase. |
|
160 |
|
161 At the end of phase two, any unfinished "maybe" features will be postponed until |
|
162 the next release. Though it shouldn't happen, any "must-have" features will |
|
163 extend phase two, and thus postpone the final release. |
|
164 |
|
165 Phase two will culminate with an alpha release. |
|
166 |
|
167 Phase three: bugfixes |
|
168 ~~~~~~~~~~~~~~~~~~~~~ |
|
169 |
|
170 The last third of a release is spent fixing bugs -- no new features will be |
|
171 accepted during this time. We'll release a beta release about halfway through, |
|
172 and an rc complete with string freeze two weeks before the end of the schedule. |
|
173 |
|
174 Bug-fix releases |
|
175 ---------------- |
|
176 |
|
177 After a minor release (i.e 1.1), the previous release will go into bug-fix mode. |
|
178 |
|
179 A branch will be created of the form ``branches/releases/1.0.X`` to track |
|
180 bug-fixes to the previous release. When possible, bugs fixed on trunk must |
|
181 *also* be fixed on the bug-fix branch; this means that commits need to cleanly |
|
182 separate bug fixes from feature additions. The developer who commits a fix to |
|
183 trunk will be responsible for also applying the fix to the current bug-fix |
|
184 branch. Each bug-fix branch will have a maintainer who will work with the |
|
185 committers to keep them honest on backporting bug fixes. |
|
186 |
|
187 How this all fits together |
|
188 -------------------------- |
|
189 |
|
190 Let's look at a hypothetical example for how this all first together. Imagine, |
|
191 if you will, a point about halfway between 1.1 and 1.2. At this point, |
|
192 development will be happening in a bunch of places: |
|
193 |
|
194 * On trunk, development towards 1.2 proceeds with small additions, bugs |
|
195 fixes, etc. being checked in daily. |
|
196 |
|
197 * On the branch "branches/releases/1.1.X", bug fixes found in the 1.1 |
|
198 release are checked in as needed. At some point, this branch will be |
|
199 released as "1.1.1", "1.1.2", etc. |
|
200 |
|
201 * On the branch "branches/releases/1.0.X", security fixes are made if |
|
202 needed and released as "1.0.2", "1.0.3", etc. |
|
203 |
|
204 * On feature branches, development of major features is done. These |
|
205 branches will be merged into trunk before the end of phase two. |