We’ve released Djblets 3.1, our collection of production-quality add-ons for Django.
This release features:
djblets.registries, djblets.secrets, and djblets.siteconfig modelsFor complete details, see the release notes.
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:
The release notes cover the full list of changes in Django Evolution 2.2.
Djblets 2.3 is now out. This release adds compatibility fixes for Python 3.10 and gets our code ready to move to newer dependencies.
Highlights include:
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.
See the release notes for the full list of changes.
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.
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.
Two important issues affecting upgrades were addressed:
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.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.
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:
Today’s release of beanbag-docutils 1.8 features:
See the release notes for the full list of changes.
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.
See the guide on adding dependencies to learn more.
Other highlights include:
See the release notes for the complete list of changes.
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:
There’s also all-new documentation, and a full breakdown of the changes in the release notes.
These are exciting times, right? While everyone is preparing for the coronavirus, we’ve been preparing for Review Board 4.0 beta 1.
And the coronavirus.
The shelves are getting pretty empty in my local grocery store, but I’ve kept my sanity.
We have an internal target date for 4.0 beta 1, which is coming up very soon, but we’re not prepared to release that just yet. Still a couple factors that might need to delay a week.
This beta will feature:
We’re working on the final bits of the administration UI, and expect to be done by end of next week. Everything is in place, with the exception of the Integrations, Extensions, and Security Center pages. But that’s it!
We’ve also been finishing up the work to make our third-party integrations (Travis-CI, Asana, Jenkins, etc.), Review Bot, and Power Pack all compatible with Review Board 4.0, Django 1.11, and Python 3. These are the last big blockers before release.
After all that is done, beta 1 will be a go!
(Assuming none of us get the coronavirus.)
If you are building custom extensions, please get ready to test this beta. Let us know if you plan to test so we can coordinate with you and give you a heads up on what may change.
RBTools 2.0 features full support for multi-commit review requests. We’ve had the bulk of this work done for a while, but have been really thoroughly testing it in preparation for a beta, which will go out alongside Review Board 4.0 beta 1.
This week, we’ve finished up the work to apply patches from a multi-commit review request (giving the ability to apply all commits sequentially or squash into a single commit), and to fully land changes.
We’re wrapping this up soon. If you test Review Board 4.0 beta 1, you’ll need RBTools 2.0 beta 1.
What else, what else..
We’re continuing to work toward improving our accessibility story in Review Board. While we’re nowhere close to where we want to be yet, we’ve amended our policies around new UI components to ensure that keyboard usage and ARIA roles are a first-class citizen in any designs.
If you make use of any assistive technologies, such as screen readers, we’d love to talk to you and get your feedback on a few things!
Review Board 4.0 will be making it easier to glance over file attachments for video files. Just like file attachment thumbnails for images and text files give you a preview of the contents, they’ll soon give you a preview of the video as well.
Hovering the mouse over these thumbnails will cause the video to play (muted) until you move the mouse away. Hovering over them again causes the video to resume from where it left off.
This is great if someone’s using video files to demonstrate their feature. We’re hoping to make this the start of some useful UI around videos.
This past week saw the development of several new accessible CSS/JavaScript components, which can be used by extensions:
We’ve historically had a few different ways to show buttons. Any <input type="button" />, <input type="submit" />, or anything with the .btn CSS class would have a consistent appearance, and could be modified by a set of additional CSS classes.
This has been revised to include <button> (which we oddly did not have before) and anything using the .rb-c-button CSS class (the successor to .btn, which is now deprecated).
A button group (.rb-c-button-group in LessCSS) is a collection of buttons, packed together either horizontally or vertically, providing an almost toolbar appearance.
The new RB.MenuView (JavaScript) and .rb-c-menu (LessCSS) component manages a pop-up menu that can be shown or hidden as needed. It supports full keyboard navigation and ARIA attributes for accessibility.
We’re working on moving to this in every place that involves a pop-up menu, including review request actions (like “Update” and “Close”) and the Account, Support, and Follow menus in the upper-right of pages.
RB.MenuButtonView (JavaScript) and .rb-c-menu-button (LessCSS) implements a type of button that displays a pop-up menu when clicked.
There are two main ways this can be used:
The later is great when you want to offer a common action, but make alternative actions easily available.
Like the new pop-up menus, these provide full keyboard navigation and ARIA attributes for accessibility, and are a great building block for extensions to use.
We hope to provide full documentation at a later time on the standard library of UI components we’re building.
KGB is our Python module for unit tests, which provides the ability to spy on any function and track the calls and results, or override the behavior. It’s incredibly powerful, and we make heavy of use of it in Review Board and all our other projects.
We’ve just fixed up KGB to work with Python 3.8, so we’re preparing for a release pretty soon.
If you’re a Python developer, check out KGB. Tell your friends. Give us some feature requests. Honestly, it’s pretty complete these days, but we need more reasons to bump the version number.
Alright, that’s enough for this ChangeLog.
We may skip next week’s ChangeLog to focus on finishing beta 1, unless we have anything really interesting to report.
If you want to know more, have any questions, or are curious about anything else, please reach out on our community forum.
We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube if you want other ways to keep up with Review Board and Beanbag.
What a week it’s been. We have two topics to go over: Last weekend’s student mentorship sprint, and a status update on the big Django upgrade.
Last weekend was our student sprint for CANOSP, kindly hosted by the Startup Edmonton in Edmonton, Canada. There, we met up with our new students from the University of Alberta and University of British Columbia, and spent the weekend getting to know them, teaching them about Review Board and how we do things here, and letting them loose on projects.
We may have been sleepy most of the time (these start early!), and VERY cold (had to sit by a stack of ice cubes to keep warm), but everyone had a lot of fun, and have since been hard at work on their projects.
The main focuses for this semester are accessibility and usability. We’re working to make the product easier to use, improving keyboard navigation, and experimenting with ways to offer useful inline help. Much of this work is slated for Review Board 4.0.
This week also marks the end of Django 1.6 in Review Board. We’ve been working for a long time on getting onto a newer version of Django, which has been a much more complex project for us than for most, and we’re finally ready to bump our Django requirement to 1.11.
For those paying attention, Django itself is at 3.0.2, but 1.11 is the last version to support Python 2.7. While Python 2.x is now end-of-life’d, that doesn’t mean it’s not in active use in enterprise, and frankly, many of our users are just not ready to upgrade. So Review Board 4.0 will continue to be providing compatibility for 2.7.
By the weekend, we should be on 1.11, and then we’ll be getting ready to test this in production. If all goes well, a beta will follow soon.
If you build extensions for Review Board, you’re going to need to make some changes to support Django 1.11. We have a bunch of useful information on Django updates on our wiki, which we’ll also include in the release notes. Make sure you give the beta a try and begin porting early.
We offer support contracts that cover development assistance, if you need it.
If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.
We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube (featuring student project videos!) if you want other ways to keep up with what we’re up to.
Hi everyone. Welcome to the first ChangeLog of 2020! We skipped last week due to the new Review Board 3.0.16 release, so let’s dive in and get caught up.
Last Tuesday, we released Review Board 3.0.16. It’s been a long time since 3.0.15, and there are two reasons for this:
We’ve discussed the repository improvements before, so read that if you want to learn a bit more, but the gist is that we’re giving SCMTools (repository backends) a lot more flexibility in how they present repository configuration, how they’re registered for use in Review Board, and how extra data for repositories get stored. This will lead to some significant improvements in the coming months for a couple of our supported repository types.
Now unless we find some major bug fixes in 3.0.16, it’ll probably be a little while until 3.0.17. We have a backlog of RBTools work we plan to release, and we’re still trying to get 4.0’s architectural rework done.
Most of the rewritten administration UI is in a usable state, and we’re just getting it all ready to be reviewed and landed. After this, we’ll be bumping our Django dependency and performing a bunch of real-world usage tests, just to make sure there isn’t some big breakage some place.
(If you want to learn more about the administration UI work and how it relates to Django and the release, read the ChangeLogs from October 24, 2019, October 31, 2019, and November 7, 2019.)
Once we’re happy, we’ll ship 4.0 Beta 1. Almost there!
Every semester, we take on a batch of CS students eager to work on some real-world project, currently as part of the CANOSP program run by the University of Alberta, Canada.
It all starts this weekend at a get-together in Edmonton, Canada, where we’ll be helping five new students get set up, go over architecture and standards, and start them on their projects.
We’ll talk more about what they’ll be working on next week, but they mostly center around quality-of-life improvements to Review Board.
If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.
We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube (featuring student project videos!) if you want other ways to keep up with what we’re up to.