Add draft release notes for 2.0.9

Review Request #6472 — Created Oct. 20, 2014 and submitted

Information

Review Board
release-2.0.x
85c3221...

Reviewers

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

Built and reviewed HTML docs.

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 …

chipx86chipx86

Past release notes contain the bug info on the summary. Same below.

chipx86chipx86

We use "rich text" and "Markdown" interchangeably in code, but I think for docs/release notes, we should probably stick with …

chipx86chipx86

Can we put the "Users can now set ..." as the start of its own paragraph? It'll flow a bit …

chipx86chipx86

We've been putting extension-related enhancements in its own Extensions section in past release notes, since most users don't care. We …

chipx86chipx86

Should go in a Web API section.

chipx86chipx86

I'd like to call the parameter rename out as its own thing, so that people can see that it's deprecated. …

chipx86chipx86

"Fixed Markdown escaping problems"

chipx86chipx86

"GitHub-Flavored Markdown"

chipx86chipx86

"Python-Markdown"

chipx86chipx86

I've been putting performance-related stuff into a "Performance Improvements" section.

chipx86chipx86

These should go in the Administration section below.

chipx86chipx86

This isn't a general bug, so let's put it in a "Repository Hooks" section.

chipx86chipx86

Should go in Dashboard.

chipx86chipx86

We should describe this. Also, this may be better in a top-level Usability section.

chipx86chipx86

Should go in Review Requests.

chipx86chipx86

Historically, I've placed Administration below the more general user-facing sections (like Diff Viewer, Review Requests, etc.) and above things like …

chipx86chipx86

Code should have double backticks. I'm not sure it's worth going into the details though. Most people reading this won't …

chipx86chipx86

We've never documented any documentation changes before, because they're just stuff up on the site. I don't mind doing it, …

chipx86chipx86

Let's capitalize Local Site, so that it's read as a thing, rather than just "sites that are local." Same below.

chipx86chipx86

Web API traditionally has had its own top-level section for any and all changes.

chipx86chipx86

Can you link to the resource? Should be: :ref:`webapi2.0-user-resource`

chipx86chipx86

Should enclose the ?stuff in double backticks. Also, maybe "it would be lost" so that it doesn't sound like it's …

chipx86chipx86
reviewbot
  1. 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
    
    
  2. 
      
chipx86
  1. 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.

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

    2. 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.
      
  2. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
     
    Show all issues

    Before this, I'd like to include an "Upgrade Notes" section like in 2.0.8 that mentions whether or not database schema changes have been made (which they have in this case).

  3. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Past release notes contain the bug info on the summary.

    Same below.

  4. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    We use "rich text" and "Markdown" interchangeably in code, but I think for docs/release notes, we should probably stick with "Markdown."

  5. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Can we put the "Users can now set ..." as the start of its own paragraph? It'll flow a bit better.

  6. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    We've been putting extension-related enhancements in its own Extensions section in past release notes, since most users don't care.

    We should also put double backticks around this.

  7. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Should go in a Web API section.

  8. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
     
     
    Show all issues

    I'd like to call the parameter rename out as its own thing, so that people can see that it's deprecated. Otherwise, it's kind of burried.

  9. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    "Fixed Markdown escaping problems"

  10. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    "GitHub-Flavored Markdown"

  11. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    "Python-Markdown"

  12. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    I've been putting performance-related stuff into a "Performance Improvements" section.

  13. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
     
     
     
    Show all issues

    These should go in the Administration section below.

  14. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    This isn't a general bug, so let's put it in a "Repository Hooks" section.

  15. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Should go in Dashboard.

  16. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    We should describe this.

    Also, this may be better in a top-level Usability section.

  17. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
     
    Show all issues

    Should go in Review Requests.

  18. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
     
    Show all issues

    Historically, I've placed Administration below the more general user-facing sections (like Diff Viewer, Review Requests, etc.) and above things like Subversion, Repository Hooks, etc. It's more the "General" of administration stuff.

  19. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Code should have double backticks.

    I'm not sure it's worth going into the details though. Most people reading this won't know or care about the technicalities. Instead, we should just change all this to say that on Firefox, you won't have to click Back twice to reach the previous page.

  20. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    We've never documented any documentation changes before, because they're just stuff up on the site. I don't mind doing it, but if we do, this should be a top-level section, rather than something in Bugs.

  21. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Let's capitalize Local Site, so that it's read as a thing, rather than just "sites that are local."

    Same below.

  22. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
     
    Show all issues

    Web API traditionally has had its own top-level section for any and all changes.

  23. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Can you link to the resource? Should be:

    :ref:`webapi2.0-user-resource`
    
  24. docs/releasenotes/2.0.9.rst (Diff revision 1)
     
     
    Show all issues

    Should enclose the ?stuff in double backticks.

    Also, maybe "it would be lost" so that it doesn't sound like it's now going to be lost?

  25. 
      
david
reviewbot
  1. Tool: PEP8 Style Checker
    Ignored Files:
        docs/releasenotes/index.rst
        docs/releasenotes/2.0.9.rst
    
    
    
    Tool: Pyflakes
    Ignored Files:
        docs/releasenotes/index.rst
        docs/releasenotes/2.0.9.rst
    
    
  2. 
      
david
reviewbot
  1. 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
    
    
  2. 
      
david
reviewbot
  1. Tool: PEP8 Style Checker
    Ignored Files:
        docs/releasenotes/index.rst
        docs/releasenotes/2.0.9.rst
    
    
    
    Tool: Pyflakes
    Ignored Files:
        docs/releasenotes/index.rst
        docs/releasenotes/2.0.9.rst
    
    
  2. 
      
chipx86
  1. Ship It!

  2. 
      
david
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-2.0.x (9cbef43)
Loading...