Release Candidate means that it contains almost all the planned features for the release and that the stability is quite good. However, not all items on our task list are checked yet so still still qualifies as a preview release.

Confirmation popup before Undo / Rollback. This is the only GUI change in this release and we have added it to make it clear that during the EAP period, reverts are not entirely safe operations. Also, during the popup display time the following background check is done:

Pre-revert check for clean working directory. When a custom change like manually edited theme file is recognized on the file system, revert is not allowed (could possibly lose user changes).

Two-way "foreign key" checks before reverts. In previous releases we had checks towards parent entities, for example, when reverting a post deletion, it was checked that the user owning the post still existed. We now also check child entities, for example, if the post creation is being reverted, it is now checked that there are no comments to that post (revert would have "orphaned" them).

Improved pre-activation checks. One of the biggest source of bug reports in previous releases was when VersionPress was installed into an environment that technically worked but was not really supported. We are continually implementing more checks and these are the new ones in RC2:

The site is not Multisite

The directories use standard WP layout

.gitignore must either not exist or contain certain rules

Web server must allow .htaccess or web.config files (this is a weak check – the initialization can continue even if this is not fulfilled and it is up to the user to correct that later)

Warning about possible timeout is displayed for sites with more than 500 entities

System info page for troubleshooting. From the pre-activation screen there is now a link to the system details page that will list info e.g. about the Git version installed, PHP version, installed WordPress plugins etc.

Customization mechanism and a customizable Git binary. One of the most common reports we were getting was "I have Git installed on my server but VersionPress still complains it's missing". Most often, the reason is that Git is installed for a different user than the web server is run as so it's not in its PATH. The Git binary can now be specified using a vpconfig.neon file, see Configuration.

Initial support for large sites. WordPress installations that contain thousands (or tens or hundreds of thousands) of entities are not a focus for v1 but we still need to make sure that we will be able to support that. So in RC2, we have updated the internal format for storing database entities and have done some initial optimization work on synchronizing entities back to the database. There is more work to come in both RC3 and future updates – for example, initializing VersionPress will currently time out on a large site and we will have a fix for that.

Note that the format change means that there is no upgrade path from RC1 and previous releases to RC2. See upgrade instructions below.

More standard error handling / logging. Up until now VersionPress captured all sorts of errors and even replaced HTTP 500 error page which was useful for debugging but not in line with how WordPress error handling / logging works. That has been removed now.

WP-CLI script for site recovery. More in this area to come.

Further investments in testing. In RC2, we finally have a test suite that covers many of the high-level scenarios using Selenium tests and some of the core functionality with unit tests. We also have a Vagrant-based environment for cross-platform testing.

X-VP-Version tag in commits. In allows future versions of VersionPress see which release created which commit (we have scenarios when this is useful).

Minor improvements to automatic change tracking. For example, options have now implemented priorities so that the more important ones appear closer to the top.

There is no upgrade path from previous versions, sorry. You have to deactivate VersionPress, upload the new version and fully reactivate again. The site history will be retained in the old format but will not be actionable – there will be no way to revert to it, etc. This is due to the change of the internal storage format, see above.