Per-ecosystem nuances
How the sealed-version suffix is encoded per ecosystem.
Last updated
How the sealed-version suffix is encoded per ecosystem.
The sp[N] suffix maps onto each ecosystem's version-string syntax. The table below uses $version for the origin version and $X for the iteration number.
Java
$groupId:$artifactId
$version+sp$X
JavaScript
$name
$version-sp$X
Python
$name
$version+sp$X
Go
$name
$version-sp$X
Ruby
$name
$version.0.1.sp$X
Debian
$name
$version+sp$X
RPM
$name
$version+sp$X
Alpine
$name
$version-r$REV
Alpine and the -r$REV revision. Alpine versioning does not append an sp suffix. Sealed iterations advance through the package-revision field (r$REV) by prepending zeros to the original revision: an origin at 8.45-r3 produces sealed iterations 8.45-r03, 8.45-r003, 8.45-r0003, and so on. This keeps the version string monotonically newer than the origin under apk's version comparator while encoding the iteration count.
The Seal Artifact Server understands two Maven-only suffixes a customer can type directly in the POM:
+safest: resolves at request time to the safest sealed iteration of the origin version.
+safest-until-<cutoff>: resolves to the safest sealed iteration Seal had published by <cutoff>, where <cutoff> is a compact ISO 8601 timestamp (YYYYMMDDTHHMMSSZ).
Both are documented in Maven-specific server features.
A sealed iteration compares greater than the bare origin version under each ecosystem's native version comparator. A manifest pin that targets exactly 2.7.4 (=2.7.4, ==2.7.4, ~=, and so on) does not match a sealed iteration unless loosened to accept the sealed form.
Last updated