Welcome to the Splat alpha!

absolutely not forwards/backwards-compatible between the versions of Django used for Review Board 3.0/4.0.

Yeah, it was pretty clear to me (from forum posts or documentation, I don't remember) that dumbdb/loaddb were only suitable for changing DB backends within the same version of Django and Review Board.  And that was my use case - I wanted to migrate from postgresql to MySQL.



guidance on alternatives

At least for postgresql->MySQL migration, I had good luck with this process:
1) use pg_dump to snapshot the existing DB (data only, not table structures)

2) use https://github.com/ChrisLundquist/pg2mysql to convert it into a MySQL-compatible format (this required a bit of manual tweaking as well, mostly to the table names in the INSERT statements, and the syntax for binary values (i.e. '\x0123456789abcdef' to X'0123456789abcdef') )

3) use 'rb-site install' to set up the new MySQL database

4) truncate the MySQL tables & load the data from the MySQL-compatible snapshot (need to disable foreign key checks during this step)
I can understand you might be reluctant to 'bless' this flow by adding it to the documentation, but it would be nice if this were documented somewhere.

After much analysis, and making a real attempt and keeping things compatible, the unfortunate conclusion is that we're removing these tools for 4.0.
As mentioned, dumpdb/loaddb are fairly thin wrappers around Django's dumpdata/loaddata, and those are absolutely not forwards/backwards-compatible between the versions of Django used for Review Board 3.0/4.0. These were never really fully built for production use anyway, more for development (in fact, loading requires a development setup).
There are plenty of issues deep within Django for compatible serialization, and we'd have to rewrite much of that stack, which isn't worth the time, given the work going into Power Pack.
We'll be adding a deprecation notice and warning when running these tools in 3.0.21, and we'll be stubbing them out entirely in 4.0, showing just an error message with guidance on alternatives.

Hmm, that's strange. Looks more like an issue in Django's code. I'll see if I can reproduce.
As mentioned on issue #4921, we're probably going to have to phase out these tools at some point, due to issues like this in Django. Native database dump/restore tools are more reliable. We do have a successor to dumpdb/loaddb that's in the works that avoids all the Django compatibility issues that these tools have (as they're based on Django's own loaddata/dumpdata, and aren't necessarily cross-version-compatible). That'll be coming as a free component to Power Pack in the future.

Thanks for the report! I see where this went wrong (Django changed how these management commands work, and it looks like this wasn't updated properly). We'll get this fixed for 4.0 final.
We are aiming to deprecate loaddb/dumpdb, as they just don't work well between releases of Django. Best bet in most situations is to use the database's native SQL dump/load tools for constructing a new database.

This is a good idea for a feature. It's probably not something we'll be putting in any time soon (we'd want to think a lot about how this would work — there are a lot of different workflows out there).
Extensions can provide this today. You can write an extension that listens to a review_request_publishing signal, check the reviewers, and raise a PublishError preventing it, if it doesn't match what's expected.

Hey Adam,
Yeah, this was part of a series of UI changes that got pushed back (there's a lot of things competing for our time.
I have some in-progress work for adding touch control and accessibility to this slider. It's missing the Review Board 4.0 release window, but I'm planning to get it into a 4.0.x.

It's been 3 years since I filed this but I just wanted to mention that this would still be really useful. I'm still unable to do interdiff manipulation on iPhone or iPad because it doesn't support dragging via touch. So I still have to manipulate the URL to pick the interdiff range.