> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/reference/naming-and-versioning/per-ecosystem.md).

# Per-ecosystem nuances

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 sealed-version number.

| Ecosystem  | Origin name            | Sealed version      |
| ---------- | ---------------------- | ------------------- |
| 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 versions advance through the package-revision field (`r$REV`) by prepending zeros to the original revision: an origin at `8.45-r3` produces sealed versions `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 sealed-version count.

## Maven extras

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 version of the origin version.
* `+safest-until-<cutoff>`: resolves to the safest sealed version Seal had published by `<cutoff>`, where `<cutoff>` is a compact ISO 8601 timestamp (`YYYYMMDDTHHMMSSZ`).

Both are documented in [Maven-specific server features](/setup-apps-os/artifact-server/maven-server-features.md).

## Java classifier artifacts

A Java dependency can carry a classifier, an optional fifth part of its coordinate (`$groupId:$artifactId:$version:$classifier`) that selects an alternate build of the same package version, such as `io.netty:netty-transport-native-epoll:4.2.6.Final:linux-x86_64`. From CLI v0.3.360, the Seal CLI scans and fixes classifier dependencies in Maven projects, Gradle projects, and loose JAR files (`--fs java`):

* The classifier is not part of the version. The dependency is reported at its origin version (`4.2.6.Final`), with that version's vulnerabilities and sealed version.
* Each classifier is sealed separately. `seal fix` installs the sealed JAR of the same classifier, named `$artifactId-$version+sp$X-$classifier.jar`, so one platform's JAR is never written over another's.
* In Gradle projects the classifier is read from the name of the cached JAR. `sources` and `javadoc` JARs are not treated as dependencies.
* A classifier artifact that Seal has not sealed is left unfixed, and the rest of the `seal fix` run continues.

## Equality and ordering

A sealed version 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 version unless loosened to accept the sealed form.

## Related

* [The `-sp[N]` model](/reference/naming-and-versioning/sp-model.md)
* [Renamed packages](/reference/naming-and-versioning/renamed-packages.md)
* [Maven-specific server features](/setup-apps-os/artifact-server/maven-server-features.md)