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.
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:
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.
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.
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)
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)
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)
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.
Preparing for Review Board 4.0 Beta 1
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:
Posting and reviewing multi-commit review requests
A brand new, streamlined, mobile-friendly administration UI
A full move to Django 1.11, with preliminary Python 3 support (which will affect extensions, so get ready)
Read-only mode, letting you prepare for an upgrade without shutting the whole server down
A new “Overview” mode in the Dashboard showing all incoming and outgoing review requests
A new integration for Jenkins CI
Live thumbnails for video file attachments
Beginnings of accessibility improvements, improving keyboard input, color contrast, and screen reader integration
An overhaul of the diff parsers, setting things up for some major future improvements to diffing capabilities (including our in-development new DiffX proposal)
Removal of a lot of deprecated internal APIs (again, this may affect extensions)
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 Beta
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.
New UI Components
New Button Classes
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.
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.
There are two main ways this can be used:
As a single button that will show some text and a drop-down indicator, used just to display the menu.
As a group of action buttons, all packed together (but visually separated), containing a final button that displays the drop-down menu.
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.
New KGB Release Coming
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.
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.
The student sprint was great!
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.
Django upgrade time!
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’ve been trying to carefully design and implement some large backend improvements for repositories and repository configuration, in collaboration with another vendor, and wanted to get it right before we released.
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.
Review Board 4.0 Status
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.