Add release notes for Review Board 6.0 beta 1.

Review Request #12929 — Created March 30, 2023 and submitted

Information

Review Board
release-6.x

Reviewers

This change adds the draft release notes for beta 1.

Built html and viewed the output.

Summary ID
Add release notes for Review Board 6.0 beta 1.
This change adds the draft release notes for beta 1. Testing Done: Built html and viewed the output.
f5f69209dab186b07f55b7f051b6a058231be380
Description From Last Updated

5.0.4 now.

chipx86chipx86

5.0.4 has a revised list/ordering here, which includes a link to Docker instructions.

chipx86chipx86

I think this should be explicit in the first sentence that Review Board's extension framework has had a concept of …

chipx86chipx86

Bug Fixes is typically last (though it can be before Internal API Changes).

chipx86chipx86

I wonder if we should just make this "Extensions", because that's the audience reading this that would be most interested …

chipx86chipx86

"If you maintain extensions ..." should be its own sentence. Alternatively, if this is in an Extensions section, then we …

chipx86chipx86

We should really update the docs on how to use TypeScript in extensions (since we need an index.ts file to …

chipx86chipx86

Two blank lines before reference definitions.

chipx86chipx86

Two blank lines before reference definitions.

chipx86chipx86

Let's move this right below Bug Fixes, to keep defect-related info together. I suspect most users won't read past the …

chipx86chipx86

The vital information/mitigation get lost here, since there's so much information in this paragraph. I think this'll read better if …

chipx86chipx86
chipx86
  1. 
      
  2. docs/releasenotes/6.0-beta-1.rst (Diff revision 1)
     
     

    5.0.4 now.

  3. docs/releasenotes/6.0-beta-1.rst (Diff revision 1)
     
     
     
     
     
     

    5.0.4 has a revised list/ordering here, which includes a link to Docker instructions.

  4. docs/releasenotes/6.0-beta-1.rst (Diff revision 1)
     
     
     
     
     
     
     
     
     
     
     
     

    I think this should be explicit in the first sentence that Review Board's extension framework has had a concept of actions. This feature won't mean anything to the average user.

  5. docs/releasenotes/6.0-beta-1.rst (Diff revision 1)
     
     
     
     
     
     
     
     
     
     

    Bug Fixes is typically last (though it can be before Internal API Changes).

  6. docs/releasenotes/6.0-beta-1.rst (Diff revision 1)
     
     
     

    I wonder if we should just make this "Extensions", because that's the audience reading this that would be most interested in this changes (and may not know the internal changes apply to them).

    We may then want to put the Actions changes in this section as well.

  7. docs/releasenotes/6.0-beta-1.rst (Diff revision 1)
     
     

    "If you maintain extensions ..." should be its own sentence.

    Alternatively, if this is in an Extensions section, then we may just want to get rid of the "particular impact on users" bit and instead say developers can now more easily integrate tools like mypy or pyright.

  8. docs/releasenotes/6.0-beta-1.rst (Diff revision 1)
     
     
     
     
     
     

    We should really update the docs on how to use TypeScript in extensions (since we need an index.ts file to trigger Rollup -- maybe worth mentioning that instead of .ts generally).

    Can you file a task for tracking an update to extension media docs?

  9. 
      
david
maubin
  1. Ship It!
  2. 
      
chipx86
  1. 
      
  2. docs/releasenotes/6.0-beta-1.rst (Diff revision 2)
     
     
     
     

    Two blank lines before reference definitions.

  3. docs/releasenotes/6.0-beta-1.rst (Diff revision 2)
     
     
     
     

    Two blank lines before reference definitions.

  4. 
      
david
chipx86
  1. 
      
  2. docs/releasenotes/6.0-beta-1.rst (Diff revision 3)
     
     
     

    Let's move this right below Bug Fixes, to keep defect-related info together. I suspect most users won't read past the internal changes info.

  3. docs/releasenotes/6.0-beta-1.rst (Diff revision 3)
     
     
     
     
     
     
     

    The vital information/mitigation get lost here, since there's so much information in this paragraph. I think this'll read better if we split it up like:

    * When a review request is open in multiple browser tabs/windows, if the review
      is discarded from one tab, attempts to create or edit comments from another tab
      will result in errors.
    
      This bug was technically present in earlier versions, but due to the way things
      are loaded from the server, it's now a lot easier to hit.
    
      The best way to avoid this for now is to avoid opening the same review request
      in multiple browser tabs.
    

    Bullet point will keep it together as one "known issue" (even though we don't have others) and will be more consistent with how we typically do Bug Fixes and such.

  4. 
      
david
chipx86
  1. Ship It!
  2. 
      
david
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-6.x (32dd9d8)
Loading...