<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Django’s release process — Django v1.2 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.2',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="top" title="Django v1.2 documentation" href="../index.html" />
<link rel="up" title="Django internals" href="index.html" />
<link rel="next" title="Django Deprecation Timeline" href="deprecation.html" />
<link rel="prev" title="Django committers" href="committers.html" />
<script type="text/javascript" src="../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django v1.2 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../index.html">Home</a> |
<a title="Table of contents" href="../contents.html">Table of contents</a> |
<a title="Global index" href="../genindex.html">Index</a> |
<a title="Module index" href="../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="committers.html" title="Django committers">previous</a>
|
<a href="index.html" title="Django internals" accesskey="U">up</a>
|
<a href="deprecation.html" title="Django Deprecation Timeline">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="internals-release-process">
<div class="section" id="s-django-s-release-process">
<span id="django-s-release-process"></span><h1>Django’s release process<a class="headerlink" href="#django-s-release-process" title="Permalink to this headline">¶</a></h1>
<div class="section" id="s-official-releases">
<span id="s-id1"></span><span id="official-releases"></span><span id="id1"></span><h2>Official releases<a class="headerlink" href="#official-releases" title="Permalink to this headline">¶</a></h2>
<p>Django’s release numbering works as follows:</p>
<ul class="simple">
<li>Versions are numbered in the form <tt class="docutils literal"><span class="pre">A.B</span></tt> or <tt class="docutils literal"><span class="pre">A.B.C</span></tt>.</li>
<li><tt class="docutils literal"><span class="pre">A</span></tt> is the <em>major version</em> number, which is only incremented for major
changes to Django, and these changes are not necessarily
backwards-compatible. That is, code you wrote for Django 6.0 may break
when we release Django 7.0.</li>
<li><tt class="docutils literal"><span class="pre">B</span></tt> is the <em>minor version</em> number, which is incremented for large yet
backwards compatible changes. Code written for Django 6.4 will continue
to work under Django 6.5.</li>
<li><tt class="docutils literal"><span class="pre">C</span></tt> is the <em>micro version</em> number which, is incremented for bug and
security fixes. A new micro-release will always be 100%
backwards-compatible with the previous micro-release.</li>
<li>In some cases, we’ll make alpha, beta, or release candidate releases.
These are of the form <tt class="docutils literal"><span class="pre">A.B</span> <span class="pre">alpha/beta/rc</span> <span class="pre">N</span></tt>, which means the <tt class="docutils literal"><span class="pre">Nth</span></tt>
alpha/beta/release candidate of version <tt class="docutils literal"><span class="pre">A.B</span></tt>.</li>
</ul>
<p>An exception to this version numbering scheme is the pre-1.0 Django code.
There’s no guarantee of backwards-compatibility until the 1.0 release.</p>
<p>In Subversion, each Django release will be tagged under <tt class="docutils literal"><span class="pre">tags/releases</span></tt>. If
it’s necessary to release a bug fix release or a security release that doesn’t
come from the trunk, we’ll copy that tag to <tt class="docutils literal"><span class="pre">branches/releases</span></tt> to make the
bug fix release.</p>
<div class="section" id="s-major-releases">
<span id="major-releases"></span><h3>Major releases<a class="headerlink" href="#major-releases" title="Permalink to this headline">¶</a></h3>
<p>Major releases (1.0, 2.0, etc.) will happen very infrequently (think “years”,
not “months”), and will probably represent major, sweeping changes to Django.</p>
</div>
<div class="section" id="s-minor-releases">
<span id="minor-releases"></span><h3>Minor releases<a class="headerlink" href="#minor-releases" title="Permalink to this headline">¶</a></h3>
<p>Minor release (1.1, 1.2, etc.) will happen roughly every nine months – see
<a class="reference internal" href="#id2">release process</a>, below for details.</p>
<p id="internal-release-deprecation-policy">These releases will contain new features, improvements to existing features, and
such. A minor release may deprecate certain features from previous releases. If a
feature in version <tt class="docutils literal"><span class="pre">A.B</span></tt> is deprecated, it will continue to work in version
<tt class="docutils literal"><span class="pre">A.B+1</span></tt>. In version <tt class="docutils literal"><span class="pre">A.B+2</span></tt>, use of the feature will raise a
<tt class="docutils literal"><span class="pre">DeprecationWarning</span></tt> but will continue to work. Version <tt class="docutils literal"><span class="pre">A.B+3</span></tt> will
remove the feature entirely.</p>
<p>So, for example, if we decided to remove a function that existed in Django 1.0:</p>
<ul class="simple">
<li>Django 1.1 will contain a backwards-compatible replica of the function
which will raise a <tt class="docutils literal"><span class="pre">PendingDeprecationWarning</span></tt>. This warning is silent
by default; you need to explicitly turn on display of these warnings.</li>
<li>Django 1.2 will contain the backwards-compatible replica, but the warning
will be promoted to a full-fledged <tt class="docutils literal"><span class="pre">DeprecationWarning</span></tt>. This warning is
<em>loud</em> by default, and will likely be quite annoying.</li>
<li>Django 1.3 will remove the feature outright.</li>
</ul>
</div>
<div class="section" id="s-micro-releases">
<span id="micro-releases"></span><h3>Micro releases<a class="headerlink" href="#micro-releases" title="Permalink to this headline">¶</a></h3>
<p>Micro releases (1.0.1, 1.0.2, 1.1.1, etc.) will be issued at least once half-way
between minor releases, and probably more often as needed.</p>
<p>These releases will always be 100% compatible with the associated minor release
– the answer to “should I upgrade to the latest micro release?” will always be
“yes.”</p>
<p>Each minor release of Django will have a “release maintainer” appointed. This
person will be responsible for making sure that bug fixes are applied to both
trunk and the maintained micro-release branch. This person will also work with
the release manager to decide when to release the micro releases.</p>
</div>
</div>
<div class="section" id="s-supported-versions">
<span id="supported-versions"></span><h2>Supported versions<a class="headerlink" href="#supported-versions" title="Permalink to this headline">¶</a></h2>
<p>At any moment in time, Django’s developer team will support a set of releases to
varying levels:</p>
<ul class="simple">
<li>The current development trunk will get new features and bug fixes
requiring major refactoring.</li>
<li>All bug fixes applied to the trunk will also be applied to the last
minor release, to be released as the next micro release.</li>
<li>Security fixes will be applied to the current trunk and the previous two
minor releases.</li>
</ul>
<p>As a concrete example, consider a moment in time halfway between the release of
Django 1.3 and 1.4. At this point in time:</p>
<ul class="simple">
<li>Features will be added to development trunk, to be released as Django 1.4.</li>
<li>Bug fixes will be applied to a <tt class="docutils literal"><span class="pre">1.3.X</span></tt> branch, and released as 1.3.1,
1.3.2, etc.</li>
<li>Security releases will be applied to trunk, a <tt class="docutils literal"><span class="pre">1.3.X</span></tt> branch and a
<tt class="docutils literal"><span class="pre">1.2.X</span></tt> branch. Security fixes will trigger the release of <tt class="docutils literal"><span class="pre">1.3.1</span></tt>,
<tt class="docutils literal"><span class="pre">1.2.1</span></tt>, etc.</li>
</ul>
</div>
<div class="section" id="s-release-process">
<span id="s-id2"></span><span id="release-process"></span><span id="id2"></span><h2>Release process<a class="headerlink" href="#release-process" title="Permalink to this headline">¶</a></h2>
<p>Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
releases every nine months, or more, depending on features.</p>
<p>After each previous release (and after a suitable cooling-off period of a week
or two), the core development team will examine the landscape and announce a
timeline for the next release. Most releases will be scheduled in the 6-9 month
range, but if we have bigger features to development we might schedule a longer
period to allow for more ambitious work.</p>
<div class="section" id="s-release-cycle">
<span id="release-cycle"></span><h3>Release cycle<a class="headerlink" href="#release-cycle" title="Permalink to this headline">¶</a></h3>
<p>Each release cycle will be split into three periods, each lasting roughly
one-third of the cycle:</p>
<div class="section" id="s-phase-one-feature-proposal">
<span id="phase-one-feature-proposal"></span><h4>Phase one: feature proposal<a class="headerlink" href="#phase-one-feature-proposal" title="Permalink to this headline">¶</a></h4>
<p>The first phase of the release process will be devoted to figuring out what
features to include in the next version. This should include a good deal of
preliminary work on those features – working code trumps grand design.</p>
<p>At the end of part one, the core developers will propose a feature list for the
upcoming release. This will be broken into:</p>
<ul class="simple">
<li>“Must-have”: critical features that will delay the release if not finished</li>
<li>“Maybe” features: that will be pushed to the next release if not finished</li>
<li>“Not going to happen”: features explicitly deferred to a later release.</li>
</ul>
<p>Anything that hasn’t got at least some work done by the end of the first third
isn’t eligible for the next release; a design alone isn’t sufficient.</p>
</div>
<div class="section" id="s-phase-two-development">
<span id="phase-two-development"></span><h4>Phase two: development<a class="headerlink" href="#phase-two-development" title="Permalink to this headline">¶</a></h4>
<p>The second third of the release schedule is the “heads-down” working period.
Using the roadmap produced at the end of phase one, we’ll all work very hard to
get everything on it done.</p>
<p>Longer release schedules will likely spend more than a third of the time in this
phase.</p>
<p>At the end of phase two, any unfinished “maybe” features will be postponed until
the next release. Though it shouldn’t happen, any “must-have” features will
extend phase two, and thus postpone the final release.</p>
<p>Phase two will culminate with an alpha release.</p>
</div>
<div class="section" id="s-phase-three-bugfixes">
<span id="phase-three-bugfixes"></span><h4>Phase three: bugfixes<a class="headerlink" href="#phase-three-bugfixes" title="Permalink to this headline">¶</a></h4>
<p>The last third of a release is spent fixing bugs – no new features will be
accepted during this time. We’ll release a beta release about halfway through,
and an rc complete with string freeze two weeks before the end of the schedule.</p>
</div>
</div>
<div class="section" id="s-bug-fix-releases">
<span id="bug-fix-releases"></span><h3>Bug-fix releases<a class="headerlink" href="#bug-fix-releases" title="Permalink to this headline">¶</a></h3>
<p>After a minor release (i.e 1.1), the previous release will go into bug-fix mode.</p>
<p>A branch will be created of the form <tt class="docutils literal"><span class="pre">branches/releases/1.0.X</span></tt> to track
bug-fixes to the previous release. When possible, bugs fixed on trunk must
<em>also</em> be fixed on the bug-fix branch; this means that commits need to cleanly
separate bug fixes from feature additions. The developer who commits a fix to
trunk will be responsible for also applying the fix to the current bug-fix
branch. Each bug-fix branch will have a maintainer who will work with the
committers to keep them honest on backporting bug fixes.</p>
</div>
<div class="section" id="s-how-this-all-fits-together">
<span id="how-this-all-fits-together"></span><h3>How this all fits together<a class="headerlink" href="#how-this-all-fits-together" title="Permalink to this headline">¶</a></h3>
<p>Let’s look at a hypothetical example for how this all first together. Imagine,
if you will, a point about halfway between 1.1 and 1.2. At this point,
development will be happening in a bunch of places:</p>
<ul class="simple">
<li>On trunk, development towards 1.2 proceeds with small additions, bugs
fixes, etc. being checked in daily.</li>
<li>On the branch “branches/releases/1.1.X”, bug fixes found in the 1.1
release are checked in as needed. At some point, this branch will be
released as “1.1.1”, “1.1.2”, etc.</li>
<li>On the branch “branches/releases/1.0.X”, security fixes are made if
needed and released as “1.0.2”, “1.0.3”, etc.</li>
<li>On feature branches, development of major features is done. These
branches will be merged into trunk before the end of phase two.</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Django’s release process</a><ul>
<li><a class="reference internal" href="#official-releases">Official releases</a><ul>
<li><a class="reference internal" href="#major-releases">Major releases</a></li>
<li><a class="reference internal" href="#minor-releases">Minor releases</a></li>
<li><a class="reference internal" href="#micro-releases">Micro releases</a></li>
</ul>
</li>
<li><a class="reference internal" href="#supported-versions">Supported versions</a></li>
<li><a class="reference internal" href="#release-process">Release process</a><ul>
<li><a class="reference internal" href="#release-cycle">Release cycle</a><ul>
<li><a class="reference internal" href="#phase-one-feature-proposal">Phase one: feature proposal</a></li>
<li><a class="reference internal" href="#phase-two-development">Phase two: development</a></li>
<li><a class="reference internal" href="#phase-three-bugfixes">Phase three: bugfixes</a></li>
</ul>
</li>
<li><a class="reference internal" href="#bug-fix-releases">Bug-fix releases</a></li>
<li><a class="reference internal" href="#how-this-all-fits-together">How this all fits together</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="committers.html">Django committers</a></li>
<li>Next: <a href="deprecation.html">Django Deprecation Timeline</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django v1.2 documentation</a>
<ul><li><a href="index.html">Django internals</a>
<ul><li>Django’s release process</li></ul>
</li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/internals/release-process.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" size="18" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Oct 20, 2010</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="committers.html" title="Django committers">previous</a>
|
<a href="index.html" title="Django internals" accesskey="U">up</a>
|
<a href="deprecation.html" title="Django Deprecation Timeline">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
distrib
>
Arklinux
>
devel
>
i586
>
media
>
main
>
by-pkgid
>
5fcb1fedf34660bc240dc59b7bfcebc4
>
files
>
297
