In-place upgrades with automatic rollback

An update has to prove itself before it replaces anything. An installation can now be updated in place, and the update behaves as a transaction rather than a swap. The new version is fetched and verified against its own signature; the running installation and its configuration are snapshotted; processing is allowed to settle; configuration is reconciled, and the reconciled values are checked to have actually taken effect; and the updated system has to pass a health gate and a functional check end to end before the update is committed. Any failure before that point rolls the installation back to what it was, automatically.

Nothing installs itself. Updates are always administrator-triggered. An installation is offered what its licence entitles it to and what it actually runs, and then it waits to be told.

What a rollback covers, said plainly. A rollback restores the installation and its configuration, and nothing else. It does not restore your database, your repository storage or your search index, and it was never going to. Take your own database backup before an upgrade, as you would before any other change of that size.

Optional components arrive the same way. Where a licence grants one, an add-on component can be added to a running installation in place, through the same fetch, verify, check and commit path. The first is web capture, which runs with a virus-scanning service beside it: a captured download that cannot be scanned is refused rather than imported.

How an installation is deployed and kept current is on the platform page.