The lowest supported version of Django is now 1.4.2.</p>
<p>The current plan is for REST framework to remain in lockstep with <ahref="https://docs.djangoproject.com/en/dev/internals/release-process/#long-term-support-lts-releases">Django's long-term support policy</a>.</p>
<h2id="django-17-support">Django 1.7 support</h2>
<p>The optional authtoken application now includes support for <em>both</em> Django 1.7 schema migrations, <em>and</em> for old-style <code>south</code> migrations.</p>
<p><strong>If you are using authtoken, and you want to continue using <code>south</code>, you must upgrade your <code>south</code> package to version 1.0.</strong></p>
<h2id="updated-test-runner">Updated test runner</h2>
<p>We now have a new test runner for developing against the project,, that uses the excellent <ahref="http://pytest.org">py.test</a> library.</p>
<p>To use it make sure you have first installed the test requirements.</p>
<p>The new test runner also includes <ahref="https://flake8.readthedocs.org">flake8</a> code linting, which should help keep our coding style consistent.</p>
<p>Note: The test case and test method matching is fuzzy and will sometimes run other tests that contain a partial string match to the given command line input.</p>
<p>The <code>@action</code> and <code>@link</code> decorators were inflexible in that they only allowed additional routes to be added against instance style URLs, not against list style URLs.</p>
<p>The <code>@action</code> and <code>@link</code> decorators have now been moved to pending deprecation, and the <code>@list_route</code> and <code>@detail_route</code> decorators have been introduced.</p>
<p>Here's an example of using the new decorators. Firstly we have a detail-type route named "set_password" that acts on a single instance, and takes a <code>pk</code> argument in the URL. Secondly we have a list-type route named "recent_users" that acts on a queryset, and does not take any arguments in the URL.</p>
<p>For more details, see the <ahref="../api-guide/viewsets">viewsets documentation</a>.</p>
<h2id="throttle-behavior">Throttle behavior</h2>
<p>There's one bugfix in 2.4 that's worth calling out, as it will <em>invalidate existing throttle caches</em> when you upgrade.</p>
<p>We've now fixed a typo on the <code>cache_format</code> attribute. Previously this was named <code>"throtte_%(scope)s_%(ident)s"</code>, it is now <code>"throttle_%(scope)s_%(ident)s"</code>.</p>
<p>If you're concerned about the invalidation you have two options.</p>
<ul>
<li>Manually pre-populate your cache with the fixed version.</li>
<li>Set the <code>cache_format</code> attribute on your throttle class in order to retain the previous incorrect spelling.</li>
<p>There are also a number of other features and bugfixes as <ahref="./topics/release-notes/#240">listed in the release notes</a>. In particular these include:</p>
<p><ahref="../api-guide/settings/#view-names-and-descriptions">Customizable view name and description functions</a> for use with the browsable API, by using the <code>VIEW_NAME_FUNCTION</code> and <code>VIEW_DESCRIPTION_FUNCTION</code> settings.</p>
<p>Smarter <ahref="../api-guide/throttling/#how-clients-are-identified">client IP identification for throttling</a>, with the addition of the <code>NUM_PROXIES</code> setting.</p>
<p>Added the standardized <code>Retry-After</code> header to throttled responses, as per <ahref="http://tools.ietf.org/html/rfc6585">RFC 6585</a>. This should now be used in preference to the custom <code>X-Trottle-Wait-Seconds</code> header which will be fully deprecated in 3.0.</p>
<p>All API changes in 2.3 that previously raised <code>PendingDeprecationWarning</code> will now raise a <code>DeprecationWarning</code>, which is loud by default.</p>
<p>All API changes in 2.3 that previously raised <code>DeprecationWarning</code> have now been removed entirely.</p>
<p>Furter details on these deprecations is available in the <ahref="./topics/2.3-announcement">2.3 announcement</a>.</p>
<h2id="labels-and-milestones">Labels and milestones</h2>
<p>Although not strictly part of the 2.4 release it's also worth noting here that we've been working hard towards improving our triage process.</p>
<p>The <ahref="https://github.com/tomchristie/django-rest-framework/issues">labels that we use in GitHub</a> have been cleaned up, and all existing tickets triaged. Any given ticket should have one and only one label, indicating its current state.</p>
<p>We've also <ahref="https://github.com/tomchristie/django-rest-framework/milestones">started using milestones</a> in order to track tickets against particular releases.</p>
<hr/>
<p><imgalt="Labels and milestones"src="../img/labels-and-milestones.png"/></p>
<p>We hope both of these changes will help make the management process more clear and obvious and help keep tickets well-organised and relevant.</p>
<h2id="next-steps">Next steps</h2>
<p>The next planned release will be 3.0, featuring an improved and simplified serializer implementation.</p>
<p>Once again, many thanks to all the generous <ahref="./topics/kickstarter-announcement/#sponsors">backers and sponsors</a> who've helped make this possible!</p>
</div><!--/span-->
</div><!--/row-->
</div><!--/.fluid-container-->
</div><!--/.body content-->
<divid="push"></div>
</div><!--/.wrapper -->
<footerclass="span12">
<p>Sponsored by <ahref="http://dabapps.com/">DabApps</a>.</a></p>
