6 files changed, 218 insertions, 23 deletions
diff --git a/docs/topics/browser-enhancements.md b/docs/topics/browser-enhancements.md
index d4e128ae..6a11f0fa 100644
--- a/docs/topics/browser-enhancements.md
+++ b/docs/topics/browser-enhancements.md
@@ -2,42 +2,63 @@
 
 > "There are two noncontroversial uses for overloaded POST.  The first is to *simulate* HTTP's uniform interface for clients like web browsers that don't support PUT or DELETE"
 >
-> &mdash; [RESTful Web Services](1), Leonard Richardson & Sam Ruby.
+> &mdash; [RESTful Web Services][cite], Leonard Richardson & Sam Ruby.
 
 ## Browser based PUT, DELETE, etc...
 
-**TODO: Preamble.**  Note that this is the same strategy as is used in [Ruby on Rails](2).
+REST framework supports browser-based `PUT`, `DELETE` and other methods, by
+overloading `POST` requests using a hidden form field.
+
+Note that this is the same strategy as is used in [Ruby on Rails][rails].
 
 For example, given the following form:
 
     <form action="/news-items/5" method="POST">
-	    <input type="hidden" name="_method" value="DELETE">
-	</form>
+        <input type="hidden" name="_method" value="DELETE">
+    </form>
 
 `request.method` would return `"DELETE"`.
 
 ## Browser based submission of non-form content
 
-Browser-based submission of content types other than form are supported by using form fields named `_content` and `_content_type`:
+Browser-based submission of content types other than form are supported by
+using form fields named `_content` and `_content_type`:
 
 For example, given the following form:
 
     <form action="/news-items/5" method="PUT">
-	    <input type="hidden" name="_content_type" value="application/json">
-		<input name="_content" value="{'count': 1}">
-	</form>
+        <input type="hidden" name="_content_type" value="application/json">
+        <input name="_content" value="{'count': 1}">
+    </form>
 
-`request.content_type` would return `"application/json"`, and `request.stream` would return `"{'count': 1}"`
+`request.content_type` would return `"application/json"`, and
+`request.stream` would return `"{'count': 1}"`
 
 ## URL based accept headers
 
+REST framework can take `?accept=application/json` style URL parameters,
+which allow the `Accept` header to be overridden.
+
+This can be useful for testing the API from a web browser, where you don't
+have any control over what is sent in the `Accept` header.
+
 ## URL based format suffixes
 
+REST framework can take `?format=json` style URL parameters, which can be a
+useful shortcut for determing which content type should be returned from
+the view.
+
+This is a more concise than using the `accept` override, but it also gives
+you less control.  (For example you can't specify any media type parameters)
+
 ## Doesn't HTML5 support PUT and DELETE forms?
 
-Nope.  It was at one point intended to support `PUT` and `DELETE` forms, but was later [dropped from the spec](3).  There remains [ongoing discussion](4) about adding support for `PUT` and `DELETE`, as well as how to support content types other than form-encoded data.
+Nope.  It was at one point intended to support `PUT` and `DELETE` forms, but
+was later [dropped from the spec][html5].  There remains
+[ongoing discussion][put_delete] about adding support for `PUT` and `DELETE`,
+as well as how to support content types other than form-encoded data.
 
-[1]: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260
-[2]: http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work
-[3]: http://www.w3.org/TR/html5-diff/#changes-2010-06-24
-[4]: http://amundsen.com/examples/put-delete-forms/
+[cite]: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260
+[rails]: http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work
+[html5]: http://www.w3.org/TR/html5-diff/#changes-2010-06-24
+[put_delete]: http://amundsen.com/examples/put-delete-forms/
diff --git a/docs/topics/credits.md b/docs/topics/credits.md
index 3f4b9f0d..1a2c0db8 100644
--- a/docs/topics/credits.md
+++ b/docs/topics/credits.md
@@ -47,6 +47,17 @@ The following people have helped make REST framework great.
 * Mattbo - [mattbo]
 * Max Hurl - [maximilianhurl]
 * Tomi Pajunen - [eofs]
+* Rob Dobson - [rdobson]
+* Daniel Vaca Araujo - [diviei]
+* Madis Väin - [madisvain]
+* Stephan Groß - [minddust]
+* Pavel Savchenko - [asfaltboy]
+* Otto Yiu - [ottoyiu]
+* Jacob Magnusson - [jmagnusson]
+* Osiloke Harold Emoekpere - [osiloke]
+* Michael Shepanski - [mjs7231]
+* Toni Michel - [tonimichel]
+* Ben Konrath - [benkonrath]
 
 Many thanks to everyone who's contributed to the project.
 
@@ -58,6 +69,8 @@ Project hosting is with [GitHub].
 
 Continuous integration testing is managed with [Travis CI][travis-ci].
 
+The [live sandbox][sandbox] is hosted on [Heroku]. 
+
 Various inspiration taken from the [Piston], [Tastypie] and [Dagny] projects.
 
 Development of REST framework 2.0 was sponsored by [DabApps].
@@ -73,12 +86,14 @@ To contact the author directly:
 [twitter]: http://twitter.com/_tomchristie
 [bootstrap]: http://twitter.github.com/bootstrap/
 [markdown]: http://daringfireball.net/projects/markdown/
-[github]: github.com/tomchristie/django-rest-framework
+[github]: https://github.com/tomchristie/django-rest-framework
 [travis-ci]: https://secure.travis-ci.org/tomchristie/django-rest-framework
 [piston]: https://bitbucket.org/jespern/django-piston
 [tastypie]: https://github.com/toastdriven/django-tastypie
 [dagny]: https://github.com/zacharyvoase/dagny
 [dabapps]: http://lab.dabapps.com
+[sandbox]: http://restframework.herokuapp.com/
+[heroku]: http://www.heroku.com/
 
 [tomchristie]: https://github.com/tomchristie
 [markotibold]: https://github.com/markotibold
@@ -124,4 +139,15 @@ To contact the author directly:
 [j4mie]: https://github.com/j4mie
 [mattbo]: https://github.com/mattbo
 [maximilianhurl]: https://github.com/maximilianhurl
-[eofs]: https://github.com/eofs
-\ No newline at end of file
+[eofs]: https://github.com/eofs
+[rdobson]: https://github.com/rdobson
+[diviei]: https://github.com/diviei
+[madisvain]: https://github.com/madisvain
+[minddust]: https://github.com/minddust
+[asfaltboy]: https://github.com/asfaltboy
+[ottoyiu]: https://github.com/OttoYiu
+[jmagnusson]: https://github.com/jmagnusson
+[osiloke]: https://github.com/osiloke
+[mjs7231]: https://github.com/mjs7231
+[tonimichel]: https://github.com/tonimichel
+[benkonrath]: https://github.com/benkonrath
diff --git a/docs/topics/csrf.md b/docs/topics/csrf.md
index a2ee1b9c..043144c1 100644
--- a/docs/topics/csrf.md
+++ b/docs/topics/csrf.md
@@ -5,8 +5,8 @@
 >  &mdash; [Jeff Atwood][cite]
 
 * Explain need to add CSRF token to AJAX requests.
-* Explain defered CSRF style used by REST framework
+* Explain deferred CSRF style used by REST framework
 * Why you should use Django's standard login/logout views, and not REST framework view
 
 
-[cite]: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
-\ No newline at end of file
+[cite]: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
diff --git a/docs/topics/release-notes.md b/docs/topics/release-notes.md
index a466f4b1..670332e6 100644
--- a/docs/topics/release-notes.md
+++ b/docs/topics/release-notes.md
@@ -4,10 +4,57 @@
 >
 > &mdash; Eric S. Raymond, [The Cathedral and the Bazaar][cite].
 
+## 2.1.2
+
+**Date**: 9th Nov 2012
+
+* **Filtering support.**
+* Bugfix: Support creation of objects with reverse M2M relations.
+
+## 2.1.1
+
+**Date**: 7th Nov 2012
+
+* Support use of HTML exception templates.  Eg. `403.html`
+* Hyperlinked fields take optional `slug_field`, `slug_url_kwarg` and `pk_url_kwarg` arguments.
+* Bugfix: Deal with optional trailing slashs properly when generating breadcrumbs.
+* Bugfix: Make textareas same width as other fields in browsable API.
+* Private API change: `.get_serializer` now uses same `instance` and `data` ordering as serializer initialization.
+
+## 2.1.0
+
+**Date**: 5th Nov 2012
+
+**Warning**: Please read [this thread][2.1.0-notes] regarding the `instance` and `data` keyword args before updating to 2.1.0.
+
+* **Serializer `instance` and `data` keyword args have their position swapped.**
+* `queryset` argument is now optional on writable model fields.
+* Hyperlinked related fields optionally take `slug_field` and `slug_url_kwarg` arguments.
+* Support Django's cache framework.
+* Minor field improvements. (Don't stringify dicts, more robust many-pk fields.)
+* Bugfix: Support choice field in Browseable API.
+* Bugfix: Related fields with `read_only=True` do not require a `queryset` argument.
+
+## 2.0.2
+
+**Date**: 2nd Nov 2012
+
+* Fix issues with pk related fields in the browsable API.
+
+## 2.0.1
+
+**Date**: 1st Nov 2012
+
+* Add support for relational fields in the browsable API.
+* Added SlugRelatedField and ManySlugRelatedField.
+* If PUT creates an instance return '201 Created', instead of '200 OK'.
+
 ## 2.0.0
 
+**Date**: 30th Oct 2012
+
 * **Fix all of the things.**  (Well, almost.)
-* For more information please see the [2.0 migration guide][migration].
+* For more information please see the [2.0 announcement][announcement].
 
 ---
 
@@ -113,4 +160,5 @@
 * Initial release.
 
 [cite]: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html
-[migration]: migration.md
-\ No newline at end of file
+[2.1.0-notes]: https://groups.google.com/d/topic/django-rest-framework/Vv2M0CMY9bg/discussion
+[announcement]: rest-framework-2-announcement.md
diff --git a/docs/topics/rest-framework-2-announcement.md b/docs/topics/rest-framework-2-announcement.md
new file mode 100644
index 00000000..885d1918
--- /dev/null
+++ b/docs/topics/rest-framework-2-announcement.md
@@ -0,0 +1,100 @@
+# Django REST framework 2
+
+What it is, and why you should care.
+
+> Most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result.
+>
+> &mdash; [Roy Fielding][cite]
+
+---
+
+**Announcement:** REST framework 2 released - Tue 30th Oct 2012 
+
+---
+
+REST framework 2 is an almost complete reworking of the original framework, which comprehensively addresses some of the original design issues.
+
+Because the latest version should be considered a re-release, rather than an incremental improvement, we've skipped a version, and called this release Django REST framework 2.0.
+
+This article is intended to give you a flavor of what REST framework 2 is, and why you might want to give it a try.
+
+## User feedback
+
+Before we get cracking, let's start with the hard sell, with a few bits of feedback from some early adopters…
+
+"Django REST framework 2 is beautiful. Some of the API design is worthy of @kennethreitz." - [Kit La Touche][quote1]
+
+"Since it's pretty much just Django, controlling things like URLs has been a breeze... I think [REST framework 2] has definitely got the right approach here; even simple things like being able to override a function called post to do custom work during rather than having to intimately know what happens during a post make a huge difference to your productivity." - [Ian Strachan][quote2]
+
+"I switched to the 2.0 branch and I don't regret it - fully refactored my code in another &half; day and it's *much* more to my tastes" - [Bruno Desthuilliers][quote3]
+
+Sounds good, right?  Let's get into some details...
+
+## Serialization
+
+REST framework 2 includes a totally re-worked serialization engine, that was initially intended as a replacement for Django's existing inflexible fixture serialization, and which meets the following design goals:
+
+* A declarative serialization API, that mirrors Django's `Forms`/`ModelForms` API.
+* Structural concerns are decoupled from encoding concerns.
+* Able to support rendering and parsing to many formats, including both machine-readable representations and HTML forms.
+* Validation that can be mapped to obvious and comprehensive error responses. 
+* Serializers that support both nested, flat, and partially-nested representations.
+* Relationships that can be expressed as primary keys, hyperlinks, slug fields, and other custom representations.
+
+Mapping between the internal state of the system and external representations of that state is the core concern of building Web APIs.  Designing serializers that allow the developer to do so in a flexible and obvious way is a deceptively difficult design task, and with the new serialization API we think we've pretty much nailed it.
+
+## Generic views
+
+When REST framework was initially released at the start of 2011, the current Django release was version 1.2.  REST framework included a backport of Django 1.3's upcoming `View` class, but it didn't take full advantage of the generic view implementations.
+
+With the new release the generic views in REST framework now tie in with Django's generic views.  The end result is that framework is clean, lightweight and easy to use.
+
+## Requests, Responses & Views
+
+REST framework 2 includes `Request` and `Response` classes, than are used in place of Django's existing `HttpRequest` and `HttpResponse` classes.  Doing so allows logic such as parsing the incoming request or rendering the outgoing response to be supported transparently by the framework.
+
+The `Request`/`Response` approach leads to a much cleaner API, less logic in the view itself, and a simple, obvious request-response cycle.
+
+REST framework 2 also allows you to work with both function-based and class-based views.  For simple API views all you need is a single `@api_view` decorator, and you're good to go.
+
+
+## API Design
+
+Pretty much every aspect of REST framework has been reworked, with the aim of ironing out some of the design flaws of the previous versions.  Each of the components of REST framework are cleanly decoupled, and can be used independantly of each-other, and there are no monolithic resource classes, overcomplicated mixin combinations, or opinionated serialization or URL routing decisions.
+
+## The Browseable API
+
+Django REST framework's most unique feature is the way it is able to serve up both machine-readable representations, and a fully browsable HTML representation to the same endpoints.
+
+Browseable Web APIs are easier to work with, visualize and debug, and generally makes it easier and more frictionless to inspect and work with.
+
+With REST framework 2, the browseable API gets a snazzy new bootstrap-based theme that looks great and is even nicer to work with.
+
+There are also some functionality improvments - actions such as as `POST` and `DELETE` will only display if the user has the appropriate permissions.
+
+![Browseable API][image]
+
+**Image above**: An example of the browseable API in REST framework 2
+
+## Documentation
+
+As you can see the documentation for REST framework has been radically improved.  It gets a completely new style, using markdown for the documentation source, and a bootstrap-based theme for the styling.
+
+We're really pleased with how the docs style looks - it's simple and clean, is easy to navigate around, and we think it reads great.
+
+## Summary
+
+In short, we've engineered the hell outta this thing, and we're incredibly proud of the result.
+
+If you're interested please take a browse around the documentation.  [The tutorial][tut] is a great place to get started.
+
+There's also a [live sandbox version of the tutorial API][sandbox] available for testing.
+
+[cite]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724
+[quote1]: https://twitter.com/kobutsu/status/261689665952833536
+[quote2]: https://groups.google.com/d/msg/django-rest-framework/heRGHzG6BWQ/ooVURgpwVC0J
+[quote3]: https://groups.google.com/d/msg/django-rest-framework/flsXbvYqRoY/9lSyntOf5cUJ
+[image]: ../img/quickstart.png
+[readthedocs]: https://readthedocs.org/
+[tut]: ../tutorial/1-serialization.md
+[sandbox]: http://restframework.herokuapp.com/
diff --git a/docs/topics/rest-hypermedia-hateoas.md b/docs/topics/rest-hypermedia-hateoas.md
index 8b0309b9..d7646892 100644
--- a/docs/topics/rest-hypermedia-hateoas.md
+++ b/docs/topics/rest-hypermedia-hateoas.md
@@ -4,7 +4,7 @@
 >
 > &mdash; Mike Amundsen, [REST fest 2012 keynote][cite].
 
-First off, the disclaimer.  The name "Django REST framework" was choosen simply to sure the project would be easily found by developers.  Throughout the documentation we try to use the more simple and technically correct terminology of "Web APIs".
+First off, the disclaimer.  The name "Django REST framework" was chosen simply to sure the project would be easily found by developers.  Throughout the documentation we try to use the more simple and technically correct terminology of "Web APIs".
 
 If you are serious about designing a Hypermedia APIs, you should look to resources outside of this documentation to help inform your design choices.
 
@@ -22,7 +22,7 @@ For a more thorough background, check out Klabnik's [Hypermedia API reading list
 
 ## Building Hypermedia APIs with REST framework
 
-REST framework is an agnositic Web API toolkit.  It does help guide you towards building well-connected APIs, and makes it easy to design appropriate media types, but it does not strictly enforce any particular design style.
+REST framework is an agnostic Web API toolkit.  It does help guide you towards building well-connected APIs, and makes it easy to design appropriate media types, but it does not strictly enforce any particular design style.
 
 ## What REST framework provides.
 
@@ -50,4 +50,4 @@ What REST framework doesn't do is give you is machine readable hypermedia format
 [parser]: ../api-guide/parsers.md
 [renderer]: ../api-guide/renderers.md
 [fields]: ../api-guide/fields.md
-[conneg]: ../api-guide/content-negotiation.md
-\ No newline at end of file
+[conneg]: ../api-guide/content-negotiation.md