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.
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.
Djblets 2.2.1 has been released, fixing an issue with building extension packages.
If a project (say, Review Board) made use of build_pipeline_settings() in its settings.py, it could cause problems when trying to build extension packages.
This happened because this function validates some paths that may not exist yet at that stage in the packaging process. This release temporarily disables path validation at this stage.
See the release notes for the full changes.
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.
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:
And plenty more.
Quite a lot!
ForeignKey or ManyToManyField)Plus lots of new features and minor bug fixes.
The full list is in the release notes.
See the documentation or start using Djblets in your own project!
In a previous post, we talked the work we’re doing to move to modern versions of Python and Django. We’re calling this the “World Update,” and it’s quite a large and difficult project.
Much of the difficulty comes from an incompatibility between how we handle database migrations (using Django Evolution) and how Django handles them (using their built-in migrations support). These aren’t at all compatible, and for many reasons (legacy support and performance), we don’t want to ditch Django Evolution. This has by far been the biggest hurdle to overcome for the World Update.
We’ve been working on this, reworking nearly all of Django Evolution to better utilize migration support in Django, to provide a new set of generic structures for describing database state and modifications, and to (soon) hook into and partly override the migration process to allow both to co-exist.
Progress on this had been steady, and we feel we’re reaching a point where we’ll be able to fully support migrations in Django Evolution.
We now have Djblets working with modern Python 3.x releases and Django 1.6 through 2.1, so we’re in good shape there.
Review Board has a large number of patches in the works to bring Python 3.x and Django 2.1 compatibility. The biggest challenge in Review Board has to do with string type safety. In Python 2.x, Unicode and byte strings are somewhat interchangeable, but there’s a sharp divide in Python 3. We’ve found many cases where we’ve made bad assumptions about string types in Review Board, and are working on both fixing these and adding strict type checks.
We’re expecting that Review Board 5.0 will require Python 3.5+ and the latest Django 2.x. Administrators will have to make sure they’re running a modern OS with the necessary version of Python, and extension authors will have some updates to perform, but in the end this will be so worth it.
We were initially hoping to release this in August, but that certainly didn’t happen. Too many things came up over this year that took away from the release.
The good news is, DVCS works, and we’re trying to polish up the experience. There’s a few other features we’re also trying to get into 4.0, but once we’re at a point where we feel people can begin safely using DVCS, the beta will start shipping. That will be… soon-ish. We’ll see what happens with the holidays.
If you’ve been on the Internet at all in the past few weeks, you’ve likely been bombarded by e-mails from every service you’ve ever used telling you that they’ve updated their privacy policy.
Yes, we’ve updated ours too, but we want to talk to you about how we manage your data, the greater picture of privacy on the Internet, the European Union’s new GDPR legislation, and why this all matters to you, no matter where you are in the world.
On May 25th, the GDPR (General Data Protection Regulation) goes into effect in the EU. It gives users there an unprecedented level of control and insight into their personal information. Amongst other things:
You must admit, that’s pretty nice. Though companies are not required to give these rights to non-EU residents, many (including us) are treating this as a new global standard.
Some parts of the GDPR are a bit vague and not all companies see eye-to-eye on the level of control you should have. We’re hoping our approach goes above and beyond.
We’ve always collected as little data as needed. We don’t need much, except to provide services to you, to aid in team communication, and to make use of third-party services we trust who help us run our business and provide support to you.
Still, under the GDPR, there was more for us to do. So here’s what we’re promising:
To help, we’ve built a whole new privacy-focused framework in Djblets to help with privacy guarantees and consent requests. All our software will be using this and we’ll be encouraging Review Board extension authors to use it. We’ll talk about this in more detail in an upcoming post.
Our Privacy Policy is up now, and will take effect on May 25th, 2018.
We’ll be activating the enhanced privacy support on RBCommons, reviewboard.org, reviews.reviewboard.org, and Splat in time for the 25th. If you’re a user on these, the next time you connect you’ll be asked to accept the Privacy Policy and to allow or block usage of your information for some services.
We’ll also be releasing Review Board 3.0.7 and Djblets 1.0.6, which are privacy-enhanced, optionally allowing for Terms of Service and Privacy Policy URLs and GDPR-compliant consent functionality. Many servers may not need this, but it’ll be available for those that do.
If you want to change, delete, or request any of your personal information from our servers, or want more information on all this, reach out to us at any time and we’ll help. You don’t need to wait for May 25th.
It’s been too long since we last ran the ChangeLog series, and felt it was the right time to start it back up again. ChangeLog is a look into the latest behind-the-scenes work going into Review Board, RBCommons, and other Beanbag projects. While intended to be a weekly series, we’d like to start off with some of the bigger tasks and feature development from the past month.
Today, all current versions of Review Board depend on Django 1.6, an old release that’s no longer supported by the Django project but is by us, and doesn’t support modern Python 3 releases.
We’ve been stuck on 1.6 because 1.7 introduced (and later mandated) a new way of handling database migrations, which is incompatible with the method we’ve always used. Reconciling the differences has been a challenge.
In the past month, we’ve made significant progress toward both the Django and Python updates:
We’ve began moving to a train model for releases, and have all of our main and upcoming products now on the calendar.
Here’s what this currently looks like:
We’re planning to release a new major Review Board release every ~6 months, meaning smaller but more frequent releases. We’re still experimenting with the schedule and timeframe for these releases.
We’ve releasing RB-Gateway 1.0 this month. This is a microservice designed to sit in front of a Git or Mercurial repository, providing an API and set of integrations that can be used by Review Board or any other tool or service for more deeply working with your repository.
RB-Gateway doesn’t change your workflow, and can be dropped in with minimal effort. It completely replaces the cgit/gitweb workaround for standalone Git repositories, and means you don’t need to set up something more complicated like GitLab just to work with Review Board.
You’ll see more information on RB-Gateway’s capabilities when we release later this month, and we’ll cover improvements being made to it here.
Those are really just the major highlights, to get everyone up to speed. It doesn’t include the new features we’ve recently built, like being able to filter files in the diff viewer based on filename patterns, a new command for creating Review Board extension source trees, the work done on kgb, or the crazy investigation into deadlocks that’s delayed Review Board 3.0.4.
Going forward, these will be smaller, covering only what’s been done over the past week. If you like these posts, and want to see this continue, please let us know! You can find us on reddit or on the community support list.
We’re still working on wrapping up 2.5, and have plans for a small 2.6, but we’re also doing some work on the large 3.0 release. This will feature a lot of things, but one of those things is a major set of improvements on top of our API.
Our API is pretty great, overall. A lot of people use it with great success in quite a number of ways. It’s lacking, though, when it comes to some of the types of queries that can be performed.
Basically, the API is nested a bit too deeply. You can’t really make a query like “Give me all diff comments across all review requests from the past year.” We want that to be possible.
We also want a flexible approach to versioning, to help us going forward. There are a lot of options for this, and some work really well for many APIs, but maybe less so for our needs.
So, I’ve been toying with all this, and put together some initial design notes on API v3.
Nothing here is set in stone. I’m totally open to feedback!
We maintain a Django application/utility framework called Djblets. Amongst other things, this provides the framework for implementing REST APIs. We use this for the Review Board API.
Review Board adds a utility layer on top of this that supports a bunch of other features, including API tokens, base test cases and utilities for API unit testing, API resource module registration/lazy lookups, and more. These are all pretty useful things, so we’ve decided to move them in to Djblets.
What this means is that, starting in Djblets 0.9, any consumers of the API will be able to offer:
This also lets us slim down the Review Board API codebase just a bit, and keep our API support consistent on future projects.
We used to have a whole, internal automated build system that tested Review Board, Djblets, Django Evolution, etc. against a variety of Python and Django versions. This was responsible for automated tests, nightly builds, website doc generation, and so on.
We’re getting this going again, but this time we’re using Travis-CI. To start off, we’re testing this with Djblets. The testing is minimal, but at least it’s there, and we’ll expand it as we go. Here it is.