IVV and IVVQ

Original wiki metadata (recorded baseline)

Status: Version-specific Documentation baseline: v4.10.0 Strategy approved: 29 September 2026

SysWarden distinguishes the assurance required for an intermediate release from full qualification of a new generation. This page explains the policy introduced for the v4.10.0 transition and future generations. It is not a release verdict and does not change the historical stable v4.04.3 procedures.

The two assurance tracks#

IVV means Integration, Verification and Validation. Intermediate Patch, Minor and Major releases require it. The release decision covers the exact candidate, CI and security results, package authenticity, installation and update behavior, and regressions selected through documented change-impact analysis.

IVVQ means Integration, Verification, Validation and Qualification. Version-specific Upgrade plans, including v5.00.0 LTS and v6.00.0, require the complete qualification plan: supported native profiles, lifecycle, migrations, HA endurance, performance, protected acceptance and verified restoration.

These are SysWarden's engineering assurance tracks, not external certification claims. Neither term promises freedom from defects.

Exact auto-versioning terminology#

The following version-specific arithmetic examples all start from v0.00.0:

Major advances the middle component to its next multiple of ten. It does not increment the first component. Upgrade increments the first component and resets the other two. Version-specific example: v4.xx.y to v5.00.0 is an Upgrade. This is the project's explicit versioning scheme; generic use of the word "major" must not replace it.

Preserve the recognized prefix in the first line of the resulting commit on main. Classification follows the original validated version transition, including across later corrective commits. A corrective PR cannot downgrade an Upgrade to IVV. The LTS label and a development estimate do not select the track or grant acceptance.

What remains mandatory for an intermediate release#

• Bind checks to exact source revisions, build inputs and package digests.
• Pass applicable CI, security and functional regression checks, including positive and negative tests of changed protections and shared dependencies.
• Cover affected installation, service lifecycle, update and recovery paths.
• Preserve native package signatures and verify the signed tag, immutable release manifest, Sigstore identity and final asset digests.
• Retain failed attempts, unresolved limitations and verified restoration.
• Complete the protected acceptance required by the selected release policy.

Long endurance campaigns are selected by impact and the release's claims for an intermediate release. They are not automatically repeated for every correction. A change to the HA mechanism or an observed regression can still require new native HA work. IVV is not permission to waive a blocking defect.

Historical evidence remains bound to its original commit and artifacts. An explicit continuity assessment may retain relevant evidence or justify a targeted replay. It must never silently relabel an old pass as a new result. The same applies to documentation-only changes: source and payload continuity must be established before evidence is admitted to a release decision.

v4.10.0 and implementation status#

The v4.10.0 Major transition completed protected IVV acceptance and was published on 1 October 2026. The protected run accepted all twelve checks, preserving each evidence set's original candidate. The tested product is 8c3405758a9b369924f466d12652e99d3a84dc56; the signed publication commit is 3cc06b62d42b5adadc46fc9a252fece5adf670c1.

All twelve public release files were downloaded and verified independently, including their original GitHub provenance attestations. The maintainer signed the exact checksum manifest using Sigstore identity laurent@data-shield.eu; see Rekor entry 3035233768.

The original protected publisher failed on a private-draft metadata read using GitHub's published-only tag endpoint. The owner explicitly approved recovery with the already verified draft ID. All frozen content, tag, protection and snapshot checks were retained; only the metadata read endpoint changed. Public downloads and signatures were reverified. The failed workflow remains recorded as failed. This bounded exception does not change normal publication policy.

This is an intermediate IVV validation, not full IVVQ. The historical HA endurance runs retain their original candidate; the current HA replay is functional. Native traffic evidence is IPv4, with IPv6 list and kernel-state checks. The private APK 3 qualification-bundle update path is outside the plan. Historical deployment runbooks retain their v4.04.3 boundary; later source builds do not inherit this release verdict.

PR273 introduced the release classification. PR280 supplied the protected intermediate acceptance producer and independent consumers. The dated policy source remains the classification reference. Frozen qualification contracts and historical verdicts are preserved.