Jump to >
Review Board 1.6 beta 1 released

Finally, definitive proof that when I don't sleep, good things happen.

Tonight (this morning?) we've released Review Board 1.6 beta 1, and there's a lot of awesome things for users and administrators alike.

Prior to 1.6, administrators that wished to limit access to repositories for different users (say, main engineering and contractors) would need to set up different Review Board deployments, which means double the maintenance and upgrade work. Anyone with access to a Review Board server had access to everything on it. No longer.

1.6 introduces access control, allowing administrators to create invite-only groups, hidden groups, and limit repository access to certain users/groups. These are all set up on the Group and Repository database pages in the administration UI. Now, you can ensure that people have access only to what they're allowed access to.

We've put together a special form of access control: Local site divisions. This is a special feature still undergoing development. it allows a single Review Board instance to be split up into different divisions that each have their own list of users, repositories, groups, and review requests. Handy for giving QA, engineering, and contractors their own separate sites, for instance. Users can only view their site (and therefore the dashboard, review request lists, groups, repositories, etc.) if they belong to that site, and it's up to administrators to decide that. This is an experimental feature and will undergo continued development over the next couple releases.

On top of all that, we've greatly enhanced our authentication backend support. Companies or organizations who have developed custom authentication backends in the past know how much a pain it is to use them with Review Board. We've fixed that in 1.6. Review Board now scans for authentication backends that comply with the new API and shows them in the list alongside Active Directory, LDAP, etc. Authentication backends can provide their own settings forms, can list the things they support (changing e-mail addresses or passwords, for instance), and then handle those types of changes.

Not to be left out, we have some great features for users as well. One-click Ship It!, collapsible reviews, Plastic SCM support, improved user pages, and user info bubbles, just to name a few.

For the full list of features in 1.6, see the release notes.

Our goal is to get through the beta cycle fast and get the final 1.6 release out the door in a couple months time. If you're planning to beta test 1.6, please let us know if you run into any problems (or even if things are working well).

Review Board 1.5.4 released

Review Board 1.5.4 is out the door, with some good bug fixes and new API functionality some people have been asking for.

We've extended the new API to bring back support for updating change numbers on review requests, and to update review requests based on change numbers. The next release of post-review will use this when working with Perforce.

There's also new API for creating, modifying, and removing repositories, which should help for large deployments tracking hundreds of Git repositories. The Repository API documentation go into some detail on this.

Along with that, we have several small fixes for problems reported since 1.5. Most only affect certain users.

Release notes are available with the complete list of fixes and improvements.

RBTools 0.3.2 released

Perforce users who switched to Review Board 1.5.2 and RBTools 0.3.1 this week hit an unfortunate problem updating review requests with change numbers. It turns out there's a validation error in our new API involving change numbers, which we'll be getting to soon.

For now, RBTools 0.3.2 is out the door, and works around this breakage by falling back to the old API. If you're on Perforce, you'll want to upgrade and make sure things are back to normal. Sorry about that!

There's also a fix for parsing CVSROOTs that don't have a username in the path, and choosing Mercurial over Perforce in a Perforce repository when there's an existing Mercurial user configuration.

As always, release notes are available.

Review Board 1.5.3 released

Another release tonight! This time, Review Board 1.5.3.

After our 1.5.2 release, some users hit issues with the new SSH infrastructure. In particular, Windows users, CVS users, and Bazaar users hit different problems. We've ironed them out and put together a new testing infrastructure here to make sure they keep working. If you've been bitten by 1.5.2 and SSH, please try this release out and let us know how it goes.

Along with this, we've updated our API so that RBTools 0.3.1 (and any other clients) can use a repository name instead of a path when creating a new review request. This greatly simplifies setting things up when there are lots of possible repository paths involved. See the RBTools 0.3.1 release announcement for some more information on this.

There are also a few other fixes thrown in. See the release notes for more information.

RBTools 0.3.1 released

RBTools 0.3.1 is out the door, with an important crash fix for users running Review Board versions older than 1.5.2, and a brand new feature sure to make administrators a bit happier.

Starting in 0.3.1, .reviewboardrc has gained a new configuration option, REPOSITORY. This can be used to override what repository information is sent to the Review Board server when creating a new review request. You can give it a different path, or, with the upcoming Review Board 1.5.3, you can give it the name of the repository (the same name you'd see for it in the New Review Request page).

This is particularly useful when repositories are SSH-backed and include a username. If you have more than two possible paths to a repository, you can choose the one to send to the server with this setting. Your upstream repository you want to use may be svn+ssh://bob@example.com/var/lib/svn, but your users may be using their own usernames instead of "bob." In these cases, you can set something like the following in your project's .reviewboardrc:

REPOSITORY = 'svn+ssh://bob@example.com/var/lib/svn'
Or even:
REPOSITORY = 'My Repository'
Assuming "My Repository" is what it's named on the server. For more information, see the release notes.