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 1.8 features:
Compatibility with Sphinx 1.7 through the latest 3.x (as of this writing, 3.5.1)
Compatibility with Django 3.x (when using the django_utils extension)
Django Evolution 2.1.2 solves a couple of issues encountered with SQLite that could happen when adding non-NULL fields to tables with existing data (leading a a SQL execution error), and possible data loss when converting a field from NULL to non-NULL.
We quietly released Djblets 2.0 a few days ago, now supporting Python 3 and Django 1.11. This is a major milestone for Djblets, as we’re finally leaving behind the formerly-necessary legacy version of Django 1.6, with our sights set on future major releases keeping up with the latest Django has to offer.
What’s Djblets?
Djblets is an add-on package for Django that provides a great deal of additions useful for building large, extensible web applications, like Review Board. This includes:
Dynamic site configuration and settings
Extension support for applications
Base for designing REST APIs
Consent-based, privacy-first foundation for features
Feature flags with extensible backends
Avatar rendering and extensible backends
Datagrid UIs
Database fields for Base64 content, atomic counters, and more
Mail sending additions supporting DMARC and smart From/Sender header spoofing
Rate limiting
Unit testing improvements
And plenty more.
What’s New?
Quite a lot!
Support for Python 2.7 and 3.6 through 3.9
Support for Django 1.11 (the last version to support Python 2.7)
New configuration forms CSS/JavaScript component library
New UIs for managing extensions and integrations
Extensions can now provide schema changes as evolutions or Django’s migrations
A new form widget for selecting related objects (for populating a ForeignKey or ManyToManyField)
Utility property for defining aliases (with optional conversion and/or deprecation warnings) to other properties
Utility property for defining properties requiring certain data types, with validation
Improved way of defining types for REST API fields
New template tags and filters for working with object data and custom template variables
RBTools 2.0 is out, bringing compatibility improvements and new features for all users. The biggest improvement is the support for Review Board 4.0’s upcoming multi-commit review requests.
Multi-Commit Review Requests
Review Board 4.0 beta 1 is coming in the next few weeks, and with RBTools 2.0, developers will be able to post a series of commits to a review request so that they can be reviewed individually or as one squashed change, depending on what the reviewer chooses to do.
Those changes can also be landed, preserving their history or squashing them back into a single commit.
To stay with the old behavior and squash the commits before posting to a review request, you can pass –squash to rbt post or rbt land (or set SQUASH_HISTORY = True or LAND_SQUASH = True, respectively, in .reviewboardrc).
This is available for both Git and Mercurial, and will require Review Board 4.0.
RBCommons users will receive multi-commit review request support in 2021.
Custom Certificate Authorities
If your Review Board server uses a self-signed certificate backed by an in-house Certificate Authority, you can now configure RBTools to recognize it through the --ca-certs, --client-key, and --client-cert options (or CA_CERTS, CLIENT_KEY, and CLIENT_CERT in .reviewboardrc).
Easier Repository Setup
rbt setup-repo has been redesigned to better help people configure their local repositories to connect to Review Board. It offers a more helpful guided setup, making it easier to find the right repository and generate your .reviewboardrc file.
Default Branches in Git
RBTools now understands the init.defaultBranch configuration for Git, helping you transition your primary branch from master to something like main.
Better Mercurial Integration
Compatibility issues are fixed, repository detection is faster, and custom scripts can benefit from performance improvements by connecting RBTools to the Mercurial command server.
And Better Perforce Integration
RBTools can work with a wider mix of configurations utilizing SSL and brokers.
There’s also a new reviewboard.repository_name Perforce counter that can tie a depot to a Review Board repository, which can be used if .reviewboardrc isn’t an option.
Plus…
Variety of improvements for Python 3 compatibility (including support for Python 3.9).
Additional Git arguments for fine-tuning rename detection.
Custom formatting for rbt status, which is useful for scripting.
rbt land and rbt patch now accept a review request URL, instead of just an ID.
rbt patch can print a patch from a review request without needing a local copy of the repository.
Just a few months ago, we released Django Evolution 2.0, the first release to support database upgrades using both Django’s migrations and our own evolutions.
Django Evolution 2.1 builds on this by introducing enhanced dependency management for evolutions and migrations. Now, an evolution (or its app) can specify other evolutions or migrations that must be applied either before or after.
Django applications that make use of swappable models can benefit from this, as an evolution defining that model can now be applied before a migration that requires it.
After 3 years of development, and a pretty massive rewrite, we’ve released Django Evolution 2.0.
Django Evolution is an add-on for Django that helps developer make and maintain changes to the schema of the database.
This is similar to (and predates) Django’s own migrations support, but allows for faster database upgrades and supports older versions of Django. It’s better suited for the needs of self-installable web applications (such as Review Board) that may go years between upgrades and need to minimize the amount of downtime.
This new major release of Django Evolution introduces:
Support for Python 2.7 and 3.5 through 3.8
Support Django 1.6 through 3.1
Full management of both evolutions and Django’s migrations, using the evolve command
Superior compatibility with a range of versions of SQLite, MySQL, MariaDB, and Postgres
Full API for fine-tune control of evolutions (useful for apps with extensions, or installers that manage an app’s database)
If you’re a regular follower of ChangeLog, you’ll notice we’ve gone from weekly to semi-monthly, and may be wondering what’s going on. Don’t worry, we’ll return to our regularly-scheduled ChangeLog in time.
We’ve been focusing heavily on wrapping up Review Board 4.0 development, testing things internally, and helping many of our support customers get out from under a backlog of internal support requests within their companies.
And just taking care of ourselves during a global pandemic.
So here’s some of what we’ve been busy with lately:
Review Board 4.0 beta and RBTools 2.0 beta preparation
Wrapping up our semester with CANOSP students
Higher Power Pack/RBCommons Trial Lengths
We’ve increased the amount of time you have to give Power Pack or RBCommons a try. Now, when you download a Power Pack license, or sign up for a team on RBCommons, you have two full months to fully explore and use the products.
We’ve applied the new trial period to all existing RBCommons customers who are still in their trial.
If you’re a Power Pack user, and have a trial license, come talk to us for an extension.
New Releases
RBTools 1.0.3
Last month, we released RBTools 1.0.3, which was long overdue. We’re going to try to release RBTools releases more frequently going forward, and we have some good stuff prepared for 1.0.4 for Perforce users coming up soon.
We also have two new releases for some tools we use to help build Review Board: kgb, and introducing babel-plugin-django-gettext.
kgb 5.0
kgb is a Python module that helps with writing unit tests, adding support for function spies. This lets you spy on any function or method, whether in your own code or elsewhere, and track all calls made to the function and inspect the results of those calls.
It’s also used to override what happens when a function is called, mocking results or behavior. This goes far beyond the capabilities of Python’s own mock patching, and instead alters things at a bytecode level. Super useful when you want to fake results from urlopen, for example.
kgb 5.0 introduces support for:
Python 3.8
New spy assertion methods, providing detailed output when they fail
Support for spying on “slippery” functions (functions generated dynamically when referencing the function itself — common in some API-wrapping Python libraries, like Stripe)
babel-plugin-django-gettext 1.0
We use Babel to let us build modern JavaScript and export it to older browsers. Something Babel allows for is custom plugins to transform JavaScript, and we’ve introduced a new plugin to help us write better localized text.
When using the standard gettext support, lines are not allowed to wrap, meaning you end up with some very long lines of text to maintain, and if you want to include the contents of variables in the text, you have to wrap in this interpolate() call, which is a pain.
This plugin takes all the annoyance out of this. Instead of writing:
var s = interpolate(
gettext('This is localizated text, and we can freely wrap lines how we want, or include variables like %(foo)s.'),
{'foo': foo},
true);
We get to write:
const s = _`
This is localizated text, and we can freely wrap
lines how we want, or include variables like ${foo}.
`;
Better, right?
If you use Babel and Django, give this plugin a try.
We’ll be releasing a new version soon with even better support for ngettext (used for strings that are based on singular/plural values) and combining with other tagged templates (like dedent).
Review Board 3.0.18 Release Prep
We’re getting close to a new Review Board 3.0.18 release. There’s a lot going into this one, but some highlights will include:
Preparation for GitHub and Bitbucket API/feature deprecations
Compatibility fixes for GitLab, Subversion, and Perforce
Improved API support for working with repositories
Faster SSH communication
Faster condensediffs for large MySQL databases
Lots of bug fixes
Expect 3.0.18 within the next two weeks.
Review Board 4.0 Release Prep
Work continues. We’ve had some people test 4.0 early, and found some regressions that pertain to extensions. We don’t want to release with those regressions in place, so we’re still iterating, but the good news is that the core product is looking pretty good now.
Remember, this release is a major architectural rewrite of the product, with equally major dependency updates, so there’s a lot to get right.
Meanwhile, we’re getting RBTools 2.0 ready for beta. This is meant to be used with Review Board 4.0, and features all the multi-commit review support, from posting changes to landing them. We’ll be shipping both at the same time.
CANOSP Student Wrap-Ups
We’ve talked before about the CANOSP student program we work with in Canada. Well, we’ve wrapped up our semester, and I can speak for the team when I say we’re going to miss working with this group.
By the way, if you’re looking to hire some strong developers coming out of college, we have plenty we can refer.
To wrap up their semester, they’ve put together some final demos of the work they’ve done, and we’d like to show them off.
Hannah Lin
Hannah worked this semester on a prototype for a new first-time setup guide for administrators, and some keyboard accessibility improvements in the diff viewer and modal dialogs, amongst other improvements. She’s also continuing on after the semester, working on a formatting toolbar for input fields.
Katherine Patenio
Katherine worked away on RBTools for most of the semester, fixing some bugs that shipped in RBTools 1.0.3, and completely reworking the rbt setup-repo experience (which we hope to ship in RBTools 2.0).
She also did a lot of work on investigating improvements to supporting users with different kinds of color-blindness, which she covers in this demo.
Monica Bui
Monica focused primarily this semester on keyboard navigation improvements in the New Review Request page (part of a big effort toward improved accessibility), and prototyping new guidance for filling in fields on a blank review request. We think that will pair nicely with work planned for Review Board 5.0.
Xiaohui Liu
Xiaohui worked on standardizing how we handle keyboard shortcuts, introducing a new registry on the page that anything can plug into to register shortcuts. This even offers a handy help screen, giving users an overview of all the keys can happily press to get their work done faster.
Xiaole Zeng
Xiaole’s projects covered help and accessibility improvements, such as adding a new Help menu to the top-right of every page (which could provide access to useful, relevant documentation), and making the review request infoboxes on the Dashboard less annoying and more keyboard-friendly. We’re looking to ship some of this in 4.0.
And that’s it for the moment
We’ll be back to a weekly format once we’ve gotten some of these releases wrapped up, and of course any time we have something pretty exciting to talk about.
Today’s release of RBTools 1.0.3 is a big one, featuring enhancements for Mercurial support, a vastly improved commit editing experience when landing changes, and several compatibility fixes for Python 3 and various types of repositories.
Landing Commits on Mercurial
rbt land now supports landing commits on Mercurial repositories.
You can land a local change from a Mercurial branch or bookmark, or a remote change from a review request. This will first verify that the change has been approved on Review Board before allowing it to land. Once approved, a new merge commit containing the information and URL of the review request will be placed on your destination branch.
This can also close the branch/bookmark being merged in on your behalf. See the documentation for details.
Improved Commit Editing
Patching a commit with rbt patch -c, or landing a commit with rbt land -e has always let you edit the message for the commit, but the experience was sub-par.
Now RBTools will mimic Git or Mercurial’s standard editing environment, helping your editor show the syntax highlighting or line length limits it would normally show.
Deleting all text in the editor and saving will cancel the patch/land operation.
You can also set a custom editor when working with RBTools by setting the new $RBTOOLS_EDITOR environment variable.
Compatibility Fixes
We’ve fixed a number of Python 3 compatibility issues. These largely centered around:
Changes in Python 3.8
Windows environment differences
Editing or processing commits containing non-ASCII characters
Normalizing URLs and paths for Subversion
Loading in Perforce metadata
Passing --help as the last argument
There’s also a fix for looking up available Git remotes for a branch when a tracking branch isn’t set. Thanks to Joshua Olson for this fix!
We’ve just gone live on a major update to the billing capabilities in RBCommons.
Try RBCommons without a credit card
With all the fraud and stolen credit card numbers out there, it’s no surprise that a lot of people wanted to try RBCommons to see if it was the right fit but weren’t comfortable providing their credit card information right away.
We’ve changed our trial so that you can sign up with only your name and e-mail address, and if you decide to keep using RBCommons, you can add your billing information later.
Separate administration and billing user roles
Many companies have a dedicated person for dealing with billing administration for services. Until now RBCommons has only had a single team administrator role, which provided access to both the billing information as well as everything else for the team. We’ve split up these responsibilities into new user roles:
A Technical Administrator can make changes to users, repositories, and other settings, but cannot change or see billing information.
A Billing Contact can see invoices and make changes to the billing information, as well as change which plan the team is on. They’ll also receive e-mails whenever we charge the attached card.
The Team Owner has access to all administration and billing capabilities. This is equivalent to the old team administrator role.
All team administrators have been updated to become Team Owners. To change a user’s roles, visit your Team Administration → Users page and click the pencil icon beside a user.
Improved invoices
Many countries require invoices to contain certain information, such as an official business name and address, or a tax ID. RBCommons now allows you to add this information in Team Admin → Account and Billing, and it will show up on your invoices.
If you’re a business located in the EU, you can put in your VAT ID and we’ll make sure that the generated invoices contain everything you need for your VAT filings.
If your country has invoice requirements that we haven’t met, please contact us.
Add billing e-mail recipients
You can now add additional e-mail addresses where you’d like any and all billing e-mails sent to. This is really useful if you have a purchasing department or some users who need to track receipts but don’t need access to RBCommons.
You can set these over in Team Admin → Account and Billing → Billing E-mails.
Update to the Privacy Policy
As part of this, we’ve made a small update to our Privacy Policy to list Quaderno as a third-party service used in our billing process. This is a good time to review your privacy choices under My Account → My Privacy Rights.
Feedback?
This has been in the works for a long time, and we’ll be iterating on it based on your feedback. So how’s it working for you? Let us know through the Need Help? button in the bottom-right of any page (opt in to Intercom in My Account → My Privacy Rights) or send us an e-mail at support@beanbaginc.com.