How QCUL Verifies the Resulting Installed Version

QCUL does not treat “installer returned without an exception” as proof that the requested version is actually installed; it verifies the resulting installed version from Joomla state/on-disk evidence.

Extension verification

QCUL re-reads the installed extension/package identity/version after Joomla Installer completes. The test result records whether the expected target version was reached rather than relying only on the updater’s requested version.

Core verification

For Joomla core, QCUL checks the actual administrator/manifests/files/joomla.xml version after finalization/cleanup. Production rollback verification also checks real on-disk/manifest evidence, not just database metadata.

If the version does not match

Treat the test as needing attention/failed. Read installer messages and logs, use the issue report, and undo/retest after resolving the cause. Do not push a package whose target-version result is unverified.

Keep the evidence chain intact

The value of How QCUL Verifies the Resulting Installed Version depends on preserving one traceable transition: known starting version, one selected update, exact captured package/hash, resulting laboratory version, automated evidence, and human review. Avoid manual package installs or unrelated lab changes that make that chain ambiguous before a production decision.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.