<!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" lang=""> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Django’s release process — Django 1.8.19 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.8.19', 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="index" title="Index" href="../genindex.html" /> <link rel="search" title="Search" href="../search.html" /> <link rel="top" title="Django 1.8.19 documentation" href="../contents.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’s security policies" href="security.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 role="document"> <div class="document"> <div id="custom-doc" class="yui-t6"> <div id="hd"> <h1><a href="../index.html">Django 1.8.19 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="security.html" title="Django&#8217;s security policies">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>Since version 1.0, Django’s release numbering works as follows:</p> <ul class="simple"> <li>Versions are numbered in the form <code class="docutils literal"><span class="pre">A.B</span></code> or <code class="docutils literal"><span class="pre">A.B.C</span></code>.</li> <li><code class="docutils literal"><span class="pre">A.B</span></code> is the <em>major version</em> number. Each version will be mostly backwards compatible with the previous release. Exceptions to this rule will be listed in the release notes. When <code class="docutils literal"><span class="pre">B</span> <span class="pre">==</span> <span class="pre">9</span></code>, the next major release will be <code class="docutils literal"><span class="pre">A+1.0</span></code>. For example, Django 2.0 will follow Django 1.9. There won’t be anything special about “dot zero” releases.</li> <li><code class="docutils literal"><span class="pre">C</span></code> is the <em>minor version</em> number, which is incremented for bug and security fixes. A new minor release will be 100% backwards-compatible with the previous minor release. The only exception is when a security or data loss issue can’t be fixed without breaking backwards-compatibility. If this happens, the release notes will provide detailed upgrade instructions.</li> <li>Before a new major release, we’ll make alpha, beta, and release candidate releases. These are of the form <code class="docutils literal"><span class="pre">A.B</span> <span class="pre">alpha/beta/rc</span> <span class="pre">N</span></code>, which means the <code class="docutils literal"><span class="pre">Nth</span></code> alpha/beta/release candidate of version <code class="docutils literal"><span class="pre">A.B</span></code>.</li> </ul> <p>In git, each Django release will have a tag indicating its version number, signed with the Django release key. Additionally, each release series has its own branch, called <code class="docutils literal"><span class="pre">stable/A.B.x</span></code>, and bugfix/security releases will be issued from those branches.</p> <p>For more information about how the Django project issues new releases for security purposes, please see <a class="reference internal" href="security.html"><span class="doc">our security policies</span></a>.</p> <dl class="glossary docutils"> <dt id="term-major-release">Major release</dt> <dd><p class="first">Major releases (A.B, A.B+1, etc.) will happen roughly every nine months – see <a class="reference internal" href="#id2">release process</a>, below for details. These releases will contain new features, improvements to existing features, and such.</p> <p id="internal-release-deprecation-policy">A major release may deprecate certain features from previous releases. If a feature is deprecated in version <code class="docutils literal"><span class="pre">A.B</span></code>, it will continue to work in versions <code class="docutils literal"><span class="pre">A.B</span></code> and <code class="docutils literal"><span class="pre">A.B+1</span></code> but raise warnings. It will be removed in version <code class="docutils literal"><span class="pre">A.B+2</span></code>.</p> <p>So, for example, if we decided to start the deprecation of a function in Django 1.7:</p> <ul class="last simple"> <li>Django 1.7 will contain a backwards-compatible replica of the function which will raise a <code class="docutils literal"><span class="pre">RemovedInDjango19Warning</span></code>. This warning is silent by default; you can turn on display of these warnings with the <code class="docutils literal"><span class="pre">-Wd</span></code> option of Python.</li> <li>Django 1.8 will still contain the backwards-compatible replica. This warning becomes <em>loud</em> by default, and will likely be quite annoying.</li> <li>Django 1.9 will remove the feature outright.</li> </ul> </dd> <dt id="term-minor-release">Minor release</dt> <dd><p class="first">Minor releases (A.B.C, etc.) will be issued as needed, often to fix security issues.</p> <p class="last">These releases will be 100% compatible with the associated major release, unless this is impossible for security reasons or to prevent data loss. So the answer to “should I upgrade to the latest minor release?” will always be “yes.”</p> </dd> </dl> </div> <div class="section" id="s-supported-versions"> <span id="s-backwards-compatibility-policy"></span><span id="supported-versions"></span><span id="backwards-compatibility-policy"></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. See <a class="reference external" href="https://www.djangoproject.com/download/#supported-versions">the supported versions section</a> of the download page for the current state of support for each version.</p> <ul> <li><p class="first">The current development master will get new features and bug fixes requiring major refactoring.</p> </li> <li><p class="first">Patches applied to the master branch must also be applied to the last major release, to be released as the next minor release, when they fix critical problems:</p> <ul class="simple"> <li>Security issues.</li> <li>Data loss bugs.</li> <li>Crashing bugs.</li> <li>Major functionality bugs in newly-introduced features.</li> </ul> <p>The rule of thumb is that fixes will be backported to the last major release for bugs that would have prevented a release in the first place (release blockers).</p> </li> <li><p class="first">Security fixes and data loss bugs will be applied to the current master, the last two major releases, and the current <a class="reference internal" href="#lts-releases"><span class="std std-ref">LTS release</span></a>.</p> </li> <li><p class="first">Documentation fixes generally will be more freely backported to the last release branch. That’s because it’s highly advantageous to have the docs for the last release be up-to-date and correct, and the risk of introducing regressions is much less of a concern.</p> </li> </ul> <p>As a concrete example, consider a moment in time halfway between the release of Django 1.7 and 1.8. At this point in time:</p> <ul class="simple"> <li>Features will be added to development master, to be released as Django 1.8.</li> <li>Critical bug fixes will be applied to the <code class="docutils literal"><span class="pre">stable/1.7.x</span></code> branch, and released as 1.7.1, 1.7.2, etc.</li> <li>Security fixes and bug fixes for data loss issues will be applied to <code class="docutils literal"><span class="pre">master</span></code> and to the <code class="docutils literal"><span class="pre">stable/1.7.x</span></code>, <code class="docutils literal"><span class="pre">stable/1.6.x</span></code>, and <code class="docutils literal"><span class="pre">stable/1.4.x</span></code> (LTS) branches. They will trigger the release of <code class="docutils literal"><span class="pre">1.7.1</span></code>, <code class="docutils literal"><span class="pre">1.6.1</span></code>, <code class="docutils literal"><span class="pre">1.4.1</span></code>, etc.</li> <li>Documentation fixes will be applied to master, and, if easily backported, to the <code class="docutils literal"><span class="pre">1.7.x</span></code> and <code class="docutils literal"><span class="pre">1.6.x</span></code> branches.</li> </ul> </div> <div class="section" id="s-long-term-support-lts-releases"> <span id="s-lts-releases"></span><span id="long-term-support-lts-releases"></span><span id="lts-releases"></span><h2>Long-term support (LTS) releases<a class="headerlink" href="#long-term-support-lts-releases" title="Permalink to this headline">¶</a></h2> <p>Additionally, the Django team will occasionally designate certain releases to be “Long-term support” (LTS) releases. LTS releases will get security and data loss fixes applied for a guaranteed period of time, typically 3+ years, regardless of the pace of releases afterwards.</p> <p>See <a class="reference external" href="https://www.djangoproject.com/download/">the download page</a> for the releases that have been designated for long-term support.</p> </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 major (i.e. 1.8, 1.9, 2.0, etc.) releases every nine months, or more, depending on features.</p> <p>After each release, and after a suitable cooling-off period of a few weeks, core developers 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 develop 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. At this point, the <code class="docutils literal"><span class="pre">stable/A.B.x</span></code> branch will be forked from <code class="docutils literal"><span class="pre">master</span></code>.</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 cycle is spent fixing bugs – no new features will be accepted during this time. We’ll try to release a beta release after one month and a release candidate after two months.</p> <p>The release candidate marks the string freeze, and it happens at least two weeks before the final release. After this point, new translatable strings must not be added.</p> <p>During this phase, committers will be more and more conservative with backports, to avoid introducing regressions. After the release candidate, only release blockers and documentation fixes should be backported.</p> <p>In parallel to this phase, <code class="docutils literal"><span class="pre">master</span></code> can receive new features, to be released in the <code class="docutils literal"><span class="pre">A.B+1</span></code> cycle.</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 major release (e.g. A.B), the previous release will go into bugfix mode.</p> <p>The branch for the previous major release (e.g. <code class="docutils literal"><span class="pre">stable/A.B-1.x</span></code>) will include bugfixes. Critical bugs fixed on master must <em>also</em> be fixed on the bugfix branch; this means that commits need to cleanly separate bug fixes from feature additions. The developer who commits a fix to master will be responsible for also applying the fix to the current bugfix branch.</p> </div> </div> </div> </div> </div> </div> <div class="yui-b" id="sidebar"> <div class="sphinxsidebar" role="navigation" aria-label="main navigation"> <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></li> <li><a class="reference internal" href="#supported-versions">Supported versions</a></li> <li><a class="reference internal" href="#long-term-support-lts-releases">Long-term support (LTS) releases</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> </ul> </li> </ul> </li> </ul> <h3>Browse</h3> <ul> <li>Prev: <a href="security.html">Django’s security policies</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 1.8.19 documentation</a> <ul><li><a href="index.html">Django internals</a> <ul><li>Django’s release process</li></ul> </li></ul> </li> </ul> <div role="note" aria-label="source link"> <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> <div id="searchbox" style="display: none" role="search"> <h3>Quick search</h3> <form class="search" action="../search.html" method="get"> <div><input type="text" name="q" /></div> <div><input type="submit" value="Go" /></div> <input type="hidden" name="check_keywords" value="yes" /> <input type="hidden" name="area" value="default" /> </form> </div> <script type="text/javascript">$('#searchbox').show(0);</script> </div> </div> <h3>Last update:</h3> <p class="topless">Mar 10, 2018</p> </div> </div> <div id="ft"> <div class="nav"> « <a href="security.html" title="Django&#8217;s security policies">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>