Versioning of Releases in Builderius
I really like the possibility of having segregated versions of the site. We have implemented such possibility in Builderius and this specific functionality is one of a kind comparing to any other WP builder! There are two strong sides related to the versioning of releases:
The most obvious reason: user has isolated and separated versions of his site – all templates, settings and template parts done in the builder; it is possible to switch to the previous version any time.
Why it is so great to have it? Imagine something does not work right in the new version that has been released just recently. User would desperately need to rollback somehow, to get back to the older version so the visitors will not experience the bug (or even security related issue!). Which are the options now? Load the older backup of DB? I think you would agree that this is not a great resolution at all! There might be some data in the new DB – users registered, orders created etc – that would be lost forever during restoring the older version of the whole DB. Better solution would be to have something like GIT versioning – and this is exactly what our site builder offers here!
With Builderius user can switch to one of the previous releases. Each release includes specific version of every template and template part plus a specific version of the global settings. It means that literally everything created inside the builder is included into the release. User has to publish the release in one click and the site looks complete and works fine.
The second reason: user can track changes and updates made along with each release!
During creation of a release user is asked to provide some additional information: release name and description. Release name should be unique. It can be a numeric version or some short name. Description should include the info about changes/updates made. So then this user or another one can understand what the specific release is about. What was done and possibly what was left to do.
Adding description to each release is very similar to creating a GIT commit. When you work on specific template/functionality – it is enough to just save changes in the template. Previewing site in the “development” mode is enough to see these changes in order to test them. And not only in one template. The changes can be made in several templates, in global settings, in template parts. All of these can be previewed in the “development” mode! After testing and make sure everything is ok – you would create a release. You would a proper description to the release. After creating the release these changes are “sealed” and “bullet proof”. After publishing the release – these changes are visible to all visitors of the site!