Our team’s been hard at work bringing RBCommons to the cutting-edge Review Board 7 platform. This is a massive update with tons of new features, and we think it’s time to give you a glimpse of what’s coming:
Multi-commit review requests for Git and Mercurial
In the past decade, DVCS has become the norm, and many people work in local branches with lots of individual commits. Previously, any code changes posted to RBCommons would show up as a squashed diff, merely showing the difference between the upstream code and the tip of the local branch.
When using DVCS systems like Git or Mercurial, RBTools will now upload the commit history of your branch. You can look at the diff of the branch as a whole, but also dig down into each individual commit.
An improved review experience
Until now, your draft review requests, reviews, and replies were all managed separately, each with their own green draft banner. While it was obvious when there was a draft review request update or a draft review, sometimes draft replies could get lost in long threads.
The new unified banner always sits at the top of the page, and collects all your work together in one place. You can also use this to publish all your drafts at once with a single click and a single-email notification.
Dark mode
There’s nothing worse than staying up late to review code and feeling blinded by your screen. With dark mode, you can reduce eye strain and work comfortably no matter the time of day.
And just so much more
There’s a lot more coming, but we wanted to keep this first message short. We’re working hard to make this transition as seamless as possible for you. Keep an eye out for more details about all the new features and a timeline for the rollout.
If you have any questions, please feel free to reply to this e-mail.
Thanks for using RBCommons! We’re excited to bring Review Board 7 to you.
This is a major feature release that introduces some new capabilities for JSON output, making it easier to integrate documentation into your own sites:
The metadata extension extracts .. meta:: into the JSON output for a page.
The json_writer extension replaces the sphinxcontrib-serializinghtml JSON writer and includes both a copy of the docs-wide Table of Contents structure in the globalcontext.fjson file and per-page anchor navigation HTML in the page’s .fjson file.
Welcome back to ChangeLog, where we dive into the latest developments around Review Board, Power Pack, and other Beanbag products.
Today we’re going to cover a major feature coming to Power Pack, plus some work that’s in progress for Review Board 6.
Office Document Review in Power Pack
Power Pack has long offered support for reviewing and diffing PDF documents. This has been used by companies to review documentation, contracts, schematics, industrial designs, and more.
Soon, you’ll be able to review a few more file types:
Microsoft Office documents (Word, Excel, PowerPoint)
It also supports diffing! You’ll be able to view the differences in new revisions of Word documents, spreadsheets, and presentations.
This will require setting up a small microservice, which we’ll provide via Docker.
When uploading a supported document to Review Board, Power Pack will send it along to the microservice to convert to PDF for render. This supports not just showing the document, but diffing multiple revisions of the document as well.
Both the original document and the PDF can also be downloaded to the local machine.
We’re expecting this will be released in Power Pack 6 by early/mid-2023.
The Unified Draft Banner
Over the years, we’ve come up with all sorts of ideas for improving the review experience in Review Board, and in Review Board 6, we’re kicking some of our plans into action, starting with the Unified Draft Banner.
This replaces the current, basic draft banners shown on review requests and reviews with a new one that:
Helps you see what all you have pending to publish (review requests, reviews, replies).
Let’s you publish them either all at once (with one combined e-mail) or individually, as before.
Shows additional information on what you’re reviewing, like the list of files in the diff viewer.
Can be further augmented by extensions.
When creating a new review request, the banner will look pretty similar to today:
When you have multiple things in flight (such as review request updates and replies to reviews), you can publish them in one go:
Or you can switch to a specific draft to publish:
The gear menu controls options for your publishes (depending on what’s being published):
The “Review” menu will always be present, and can be used to guide users to creating a new review, adding general comments, and quickly posting a Ship It! review.
This is still in the early stages. We’ll provide some more screenshots as development progresses.
Actions Rewrite
Behind-the-scenes, we have the “actions” system, which lets Review Board and extensions register buttons in some parts of the review request UI. It’s where the “Ship It!”, “Close”, “Upload Diff”, etc. buttons all come from.
The existing system is, let’s be honest, a bit of a mess. It grew organically, and we kept bolting things onto the design. There are class-based review request actions, dictionary-based review request actions, two forms of header actions, and several other purpose-built types. Keeping this maintainable has been a problem.
So this is finally getting a major overhaul. The new design is a lot more reasonable for both us and extension authors to work with. With this, we’re aiming for:
Better keyboard shortcuts throughout the product.
Improved accessibility.
Newer UI features like a possible Command-K bar (a sort of command-line-in-browser interface, similar to macOS Spotlight, Alfred, and other tools).
Once this is further along, we’ll have more to show off.
Looking Toward Review Board 6
With Review Board 6, we’re heavily focusing on improvements to the review process. There’s more to talk about, but we’ll save those for a future ChangeLog (available on this blog, Reddit, Mastodon, Twitter, or Facebook).
We’re aiming to for a mid-2023 release date for Review Board 6. This is a shorter release cycle than most of our large releases, and that’s the plan going forward. We want to get new features our faster, with smaller, focused releases.
Django Evolution 2.2 is a major feature release, offering new database features, improved compatibility, and several bug fixes.
Django Evolution is our alternative database migration library for Django, which supports a wide range of Django versions and optimized application of database changes. It targets self-managed applications, like Review Board, which may potentially go several releases between upgrades.
The highlights include:
Compatibility with Django 1.6 through 4.1, and Python 2.7 through 3.11
Support for conditions, expressions, opclasses, and field lists in Django’s Index classes.
beanbag-docutils is a set of extensions to the Sphinx ReStructuredText-based documentation system used by our products to help generate better documentation. Amongst other enhancements, it provides:
Enhancements for Sphinx’s intersphinx system to provide per-page intersphinx resolution options (useful for pages, such as release notes, that need to link to different versions of the same docs, such as Django or Python)
Enhancements to ReStructuredText references to let a reference name span lines (useful for long Python/JavaScript module/class names)
Linking code references to GitHub documentation
High-DPI image embedding
A role for HTTP status codes
Today’s release of beanbag-docutils 2.0 features:
Python 3.11 support, and the removal of Python 2.7
Improved Sphinx configuration defaults when using autodoc_utils.
New autodoc sections for documenting attribute/property types (Type:), dictionary keys (Keys:), and tuples (Tuple:)
Fixes for lists within version sections (Version Added:, Version Changed:, and Deprecated:)
Fixes and improvements for linking to code on GitHub
Support for caching data in cache_memoize() without needing to wrap in a list or string.
We’re getting 3.x ready for release. This will move the codebase to require Python 3.7+ and Django 3.2 LTS, finally bringing support for modern codebases.
Django Evolution 2.1.3 a small but important bug fix release that addresses issues with Python 3.10, mysqlclient, and evolving very old databases.
Compatibility Fixes
Python 3.10 removed some deprecated imports from collections, which Django 2.0 and older depend on. When using this combination of versions, Django Evolution will bring back those legacy imports, allowing Django to work again.
mysqlclient also received a similar fix. Django 1.11 and older depended on some unintentional functionality, which mysqlclient maintained until the 2.1 release. We now patch these versions of Django at runtime to continue working.
Upgrade Fixes
Two important issues affecting upgrades were addressed:
Django Evolution no longer tries to apply evolutions to models that were just introduced. This was a regression from previous releases.
When upgrading from very old databases, some state for a model’s unique_together index couldn’t be compared properly, causing issues applying some upgrades. The old format for this state is now taken into account during comparison.
Coming Up…
We’re preparing Django Evolution 2.2, which will support all versions of Django up through 4.0. This should be coming soon.
In the meantime, check out the release notes for the full changes, including other fixes in this release.
