What Production Changes Can Invalidate a Tested Update

Some production changes directly invalidate the assumptions behind a tested update and should stop the push until the laboratory test is refreshed.

Changes that matter directly

• The selected extension or Joomla core starting version changed on production.
• The exact captured package is missing or no longer matches its recorded SHA-256.
• The current Joomla root/site identity is not the production target used by the workflow.
• Required permissions/storage/worker environment changed so the controlled operation cannot run safely.
• A newer/conflicting QCUL production operation superseded the tested item/checkpoint context.

When to create a fresh laboratory

If production has moved to a different starting version for the selected target, refresh the laboratory from current production and retest the update. A successful rehearsal against the old starting version is not evidence for a new transition.

Do not confuse content edits with target-version changes

A new article or unrelated extension configuration change can be recorded as context without automatically invalidating the tested package. Focus on whether the selected update’s preconditions are still true.

Production change rule

For What Production Changes Can Invalidate a Tested Update, the live site should change only through the explicit tested-item production workflow after current readiness checks pass. Do not substitute a new package, skip the review/protection decision, or run a second production action while QCUL already owns an active push/rollback state.

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.