release: freeze Nexus One AI 1.0.0-rc1
This commit is contained in:
Jino Jose committed
1 parent
63acefd890
commit
4f1419ca93
152 files changed
+9445
-828
No files matched your search
@@ -0,0 +1,167 @@
|
||||
# Release Naming, Provenance, Retention, and Support Lifecycle
|
||||
|
||||
**Status**: Approval draft; no release authority.
|
||||
|
||||
## Artifact Identity
|
||||
|
||||
Artifact identity is independent of filename. The canonical identity tuple is artifact type, product,
|
||||
CPU architecture, release version, source revision, manifest digest, signing-key ID and whole-artifact
|
||||
digest. Two byte-different artifacts never share the same complete identity, even if filenames match.
|
||||
|
||||
## Versioning
|
||||
|
||||
Nexus One AI platform releases use Semantic Versioning `MAJOR.MINOR.PATCH`:
|
||||
|
||||
- `MAJOR`: customer-impacting compatibility or migration boundary requiring explicit upgrade policy.
|
||||
- `MINOR`: backward-compatible capability, supported hardware/profile or operational expansion.
|
||||
- `PATCH`: backward-compatible defect/security fix without entitlement expansion.
|
||||
|
||||
Prerelease identifiers are `dev.N`, `alpha.N`, `beta.N`, `rc.N` and are never generally releasable.
|
||||
Build metadata MAY identify a reproducibility rerun but cannot distinguish customer-visible content;
|
||||
any payload change increments the release/prerelease version. Security floor and supported upgrade
|
||||
range use parsed semantic versions, never lexical comparison.
|
||||
|
||||
Models have their upstream immutable revision plus a Cezen pack revision, for example pack
|
||||
`1.0.0` containing a named upstream commit/manifest digest. Trust bundles have monotonically increasing
|
||||
policy versions and cannot be rolled back below the active signed floor.
|
||||
|
||||
## Canonical Product and Filename Slugs
|
||||
|
||||
| Artifact | Canonical artifact type/product slug | Filename pattern |
|
||||
|---|---|---|
|
||||
| Online Universal Server ISO | `iso-online-server-universal` | `nexus-one-ai-online-server-universal_<version>_<arch>.iso` |
|
||||
| Offline Workstation ISO | `iso-offline-workstation` | `nexus-one-ai-offline-workstation_<version>_<arch>.iso` |
|
||||
| Offline Server S/M ISO | `iso-offline-server-sm` | `nexus-one-ai-offline-server-sm_<version>_<arch>.iso` |
|
||||
| Offline Server L/Max ISO | `iso-offline-server-lmax` | `nexus-one-ai-offline-server-lmax_<version>_<arch>.iso` |
|
||||
| Model pack | `model-pack-<model-slug>` | `nexus-one-ai-model-pack_<model-slug>_<upstream-revision>_<pack-version>_<arch>.tar.zst` |
|
||||
| Offline update | `update-bundle` | `nexus-one-ai-update_<from-range>_to_<version>_<arch>.tar.zst` |
|
||||
| Trust bundle | `trust-bundle` | `nexus-one-ai-trust_<policy-version>.json` |
|
||||
|
||||
Filenames use lowercase ASCII slugs, semantic versions, explicit architecture and no spaces. Filename
|
||||
is display/convenience metadata and is never trusted without signed-manifest verification.
|
||||
|
||||
## Release Channels
|
||||
|
||||
| Channel | Permitted artifacts | Promotion rule |
|
||||
|---|---|---|
|
||||
| `development` | Internal unsigned build outputs allowed only in isolated build/test systems | Never delivered to customers |
|
||||
| `internal` | Signed prerelease | Static/schema/security tests and reproducible identity pass |
|
||||
| `pilot` | Signed RC | Required physical/offline/update/recovery evidence plus pilot authorization |
|
||||
| `stable` | Signed final | All gates, independent review and joint product/delivery approval pass |
|
||||
| `security` | Signed targeted update/trust bundle | Security-owner scope plus product/delivery recovery approval |
|
||||
|
||||
Promotion does not rename or mutate bytes. A promoted release is rebuilt under a new final version or
|
||||
the exact already-signed artifact is referenced by a new signed channel index according to approved
|
||||
policy; silent replacement is prohibited.
|
||||
|
||||
## SBOM
|
||||
|
||||
Every ISO payload, model pack and update bundle includes:
|
||||
|
||||
- SPDX 3.0.1 JSON as the canonical release SBOM;
|
||||
- package/file/component identities, versions, suppliers, licenses, checksums and relationships;
|
||||
- OS packages, Python/Conda packages, container images/layers, binaries, source package, JavaScript
|
||||
assets, models/runtime objects and embedded build/install tools;
|
||||
- generated timestamp and tool identity separated from reproducible component content;
|
||||
- declared unknown/incomplete license fields as release blockers, not guessed values.
|
||||
|
||||
CycloneDX MAY be generated as an additional customer/tooling view but cannot replace canonical SPDX.
|
||||
Model SBOM entries include provider, model/revision, weight/config/tokenizer/template/license object
|
||||
digests and declared runtime relationship.
|
||||
|
||||
## Provenance
|
||||
|
||||
Every built artifact carries an in-toto Attestation Framework v1.2 Statement v1 using the
|
||||
SLSA Provenance v1 predicate (aligned to the SLSA specification v1.2), encoded as
|
||||
canonical JSON and referenced by digest from the artifact manifest. It identifies:
|
||||
|
||||
- source repository and exact revision plus clean/dirty state;
|
||||
- build recipe/revision, resolved immutable inputs and dependency/object digests;
|
||||
- builder identity, isolated environment image/OS/tool versions and architecture;
|
||||
- build start/end, invocation parameters excluding secrets, network policy and reproducibility status;
|
||||
- output artifact/manifest/SBOM digests and signing handoff identity.
|
||||
|
||||
The signing event is a separate attestation linking verified build output to release key/policy,
|
||||
reviewer and channel. Private-key location, credential values and sensitive host details are excluded.
|
||||
|
||||
## Reproducibility Classification
|
||||
|
||||
- `reproducible`: independent authorized rebuilds produce identical whole-artifact bytes/digest.
|
||||
- `content-reproducible`: all signed payload objects/manifests match but ISO container bytes differ only
|
||||
in documented non-semantic metadata that is excluded from trusted content identity.
|
||||
- `non-reproducible`: unexplained content or container differences; cannot enter stable channel.
|
||||
|
||||
Timestamps, file ordering, ownership/mode, locale, compression, ISO volume metadata and generated IDs
|
||||
must be normalized where tooling permits. Differences are stored and reviewed, not waived silently.
|
||||
|
||||
## Release Record and Publication
|
||||
|
||||
The release record contains version/channel/status, every artifact identity, source/build provenance,
|
||||
SBOM, license review, security findings, supported category/tier/architecture/hardware/OS matrix,
|
||||
upgrade/from-version and rollback class, known issues, evidence links/checksums, release notes, support
|
||||
window and named approvals. Publication includes manifest/signature/digest and verification guidance.
|
||||
|
||||
An artifact is never “latest” solely because a filename or repository branch is newer. Signed channel
|
||||
indexes map `stable`/`pilot` to immutable artifact identity and retain history.
|
||||
|
||||
## Retention
|
||||
|
||||
Recommended minimums pending owner approval:
|
||||
|
||||
- Stable release records, manifests, signatures, SBOMs, provenance, approvals and checksums: product
|
||||
lifetime plus seven years.
|
||||
- Stable ISO/update/model/trust bytes: while supported plus two years, subject to redistribution rights.
|
||||
- Pilot/RC evidence and failed critical release candidates: seven years.
|
||||
- Internal/development artifact bytes: 90 days unless referenced by an investigation; metadata one year.
|
||||
- Revoked/withdrawn artifacts: retain controlled bytes and permanent public/internal tombstone identity;
|
||||
never delete the fact that the artifact existed.
|
||||
- Raw lab captures/logs: approved evidence retention, access and privacy schedule; summary/checksums
|
||||
follow the release record.
|
||||
|
||||
Retention expiration requires recorded disposition; signed metadata, security/revocation history and
|
||||
customer restore dependencies cannot be deleted merely to save storage.
|
||||
|
||||
## Support Window and Cadence
|
||||
|
||||
Proposed policy for approval:
|
||||
|
||||
- One current stable `MAJOR.MINOR` line plus the immediately previous minor receives standard fixes.
|
||||
- Critical security updates may target older supported appliances when upgrade is unsafe; unsupported
|
||||
lines receive a signed upgrade/recovery recommendation, not an untested patch.
|
||||
- Patch/update bundles are issued as required after gates; there is no forced monthly payload churn.
|
||||
- Quarterly dependency/model/runtime review determines whether a maintenance release is needed.
|
||||
- ISO refresh occurs after accepted updates materially affect clean installation, security, hardware
|
||||
enablement or field time; installed systems use update bundles rather than OS reinstall.
|
||||
- Model packs have independent revisions/support notices and do not force platform release unless
|
||||
runtime compatibility changes.
|
||||
- Trust/revocation bundles publish immediately for approved emergency changes and on the regular
|
||||
maximum-age cadence required by policy.
|
||||
|
||||
Every release states end-of-support date or governing policy, minimum supported update source,
|
||||
successor release and recovery/upgrade path. No auto-update occurs without the appliance update policy.
|
||||
|
||||
## Withdrawal and Revocation
|
||||
|
||||
A withdrawn artifact remains identifiable by digest and status. Signed channel indexes stop selecting
|
||||
it; trust/revocation policy may block new installation/import while preserving recovery-safe behavior
|
||||
for already-running appliances. The notice records reason/severity, affected identities, customer
|
||||
impact, replacement, backup/rollback advice and support contact without exposing exploit details
|
||||
beyond approved disclosure policy.
|
||||
|
||||
## Evidence Gate
|
||||
|
||||
1. Validate filenames and manifest identity for every artifact type and architecture.
|
||||
2. Generate/validate SPDX and provenance schemas; reconcile all inventory objects.
|
||||
3. Rebuild independently and classify reproducibility with documented diff.
|
||||
4. Verify signed channel index promotion never mutates referenced bytes.
|
||||
5. Exercise withdrawal/revocation and older-version upgrade/restore discovery.
|
||||
6. Confirm retention and publication locations are access-controlled, backed up and restorable.
|
||||
7. Product, security, legal and delivery/support approve support/retention/cadence values.
|
||||
|
||||
## Owner Decisions Still Open
|
||||
|
||||
- Approve SPDX 3.0.1 and in-toto v1.2/SLSA v1.2 formats/toolchain and reproducibility classification.
|
||||
- Approve filename/version/channel rules and production publication locations.
|
||||
- Approve retention periods, raw-evidence privacy schedule and legal hold.
|
||||
- Approve supported-version window, security backport policy, review/ISO refresh cadence and EOL notice.
|
||||
- Name release coordinator, SBOM/license owner, provenance reviewer and archive owner.
|
||||
Reference in new issue
Block a user