Summary

Add draft release notes for 2.0.9

Review Request #6472 — Created Oct. 20, 2014 and submitted Oct. 22, 2014, 12:01 a.m.

Information

Owner

david

Repository

Review Board

Branch

release-2.0.x

Bugs

Depends On

Commit

85c3221...

Reviewers

Groups

reviewboard

People

Description

This covers all of the changes that will ship in 2.0.9.

Testing Done

Built and reviewed HTML docs.

Issues

Description	From	Last Updated
Before this, I'd like to include an "Upgrade Notes" section like in 2.0.8 that mentions whether or not database schema …	chipx86	Oct. 20, 2014, 2:52 p.m.
Past release notes contain the bug info on the summary. Same below.	chipx86	Oct. 20, 2014, 2:53 p.m.
We use "rich text" and "Markdown" interchangeably in code, but I think for docs/release notes, we should probably stick with …	chipx86	Oct. 20, 2014, 2:54 p.m.
Can we put the "Users can now set ..." as the start of its own paragraph? It'll flow a bit …	chipx86	Oct. 20, 2014, 2:54 p.m.
We've been putting extension-related enhancements in its own Extensions section in past release notes, since most users don't care. We …	chipx86	Oct. 20, 2014, 2:54 p.m.
Should go in a Web API section.	chipx86	Oct. 20, 2014, 2:55 p.m.
I'd like to call the parameter rename out as its own thing, so that people can see that it's deprecated. …	chipx86	Oct. 20, 2014, 2:56 p.m.
"Fixed Markdown escaping problems"	chipx86	Oct. 20, 2014, 2:55 p.m.
"GitHub-Flavored Markdown"	chipx86	Oct. 20, 2014, 2:56 p.m.
"Python-Markdown"	chipx86	Oct. 20, 2014, 2:56 p.m.
I've been putting performance-related stuff into a "Performance Improvements" section.	chipx86	Oct. 20, 2014, 2:59 p.m.
These should go in the Administration section below.	chipx86	Oct. 20, 2014, 2:59 p.m.
This isn't a general bug, so let's put it in a "Repository Hooks" section.	chipx86	Oct. 20, 2014, 2:59 p.m.
Should go in Dashboard.	chipx86	Oct. 20, 2014, 3 p.m.
We should describe this. Also, this may be better in a top-level Usability section.	chipx86	Oct. 20, 2014, 3:01 p.m.
Should go in Review Requests.	chipx86	Oct. 20, 2014, 3:01 p.m.
Historically, I've placed Administration below the more general user-facing sections (like Diff Viewer, Review Requests, etc.) and above things like …	chipx86	Oct. 20, 2014, 3:02 p.m.
Code should have double backticks. I'm not sure it's worth going into the details though. Most people reading this won't …	chipx86	Oct. 20, 2014, 3:02 p.m.
We've never documented any documentation changes before, because they're just stuff up on the site. I don't mind doing it, …	chipx86	Oct. 20, 2014, 3:02 p.m.
Let's capitalize Local Site, so that it's read as a thing, rather than just "sites that are local." Same below.	chipx86	Oct. 20, 2014, 3:03 p.m.
Web API traditionally has had its own top-level section for any and all changes.	chipx86	Oct. 20, 2014, 3:03 p.m.
Can you link to the resource? Should be: :ref:`webapi2.0-user-resource`	chipx86	Oct. 20, 2014, 3:04 p.m.
Should enclose the ?stuff in double backticks. Also, maybe "it would be lost" so that it doesn't sound like it's …	chipx86	Oct. 20, 2014, 3:04 p.m.

Tool: Pyflakes
Ignored Files:
    docs/releasenotes/index.rst
    docs/releasenotes/2.0.9.rst



Tool: PEP8 Style Checker
Ignored Files:
    docs/releasenotes/index.rst
    docs/releasenotes/2.0.9.rst

Most of my comments have to do with organization of the release notes. I've been trying to create some consistency with the ordering and presence of top-level groups (the new Upgrade Notes section, Features, Performance Improvements, Usability, Extensions, Web API, Bug Fixes, Contributors), and sub-groups within Bug Fixes, and want to keep that from changing too much.

I also think it's worth adding that force_text_type= can be used in POST/PUT, since that's useful and balances out the ?force-text-type= in GET. It's not inheritently specific to what's coming in 2.0.10.

david Oct. 20, 2014, 3:21 p.m.

Can you come up with some text for that? I don't have that all still in my head.

chipx86 Oct. 20, 2014, 3:29 p.m.

Sure. I guess there's a few related items. How about:

* POST and PUT requests can now force the returned text types in payloads.

  GET requests were able to set ``?force-text-type=`` to force any text fields
  capable of rich text to be converted to the requested type in the returned
  payload. POST and PUT requests now have this ability as well by setting
  ``force_text_type=`` in the request data to the desired text type.

* Custom text fields provided by extensions can now have their text type forced.

  Extensions may provide custom rich text fields, which have their values stored
  in ``extra_data`` in the payload. These values will now respect the
  ``?force-text-type=`` and ``force_text_type=`` arguments in requests.

* Added support for forcing text to HTML in requests.

  ``"html"`` is now a valid value for ``?force-text-type=`` and
  ``force_text_typ=``. The text, whether plain text or Markdown, will be
  rendered to HTML.

docs/releasenotes/2.0.9.rst (Diff revision 1)