> 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/sp-model.md).

# The -sp\[N] model

The -sp\[N] versioning model Seal uses for sealed versions, and the private-version sp\[N]p\[M] suffix.

A sealed version's identity is the origin version's identity plus an sealed-version suffix. The canonical form is `sp` followed by a positive integer. The exact placement and separator vary by ecosystem (see [Per-ecosystem nuances](/reference/naming-and-versioning/per-ecosystem.md)).

For `ejs@2.7.4`, the first sealed version is `2.7.4-sp1`, the second is `2.7.4-sp2`, and so on. Both substitute for `2.7.4` in any context that accepts `2.7.4`; what differs is the set of vulnerabilities each one closes.

## Why N increments

The sealed-version number grows whenever Seal produces a new sealed version of the same origin version. Reasons:

* A new vulnerability is disclosed against the previously latest sealed version. Seal builds a new sealed version that closes the new vulnerability in addition to the ones the earlier sealed versions closed.
* Coverage is expanded. Seal extends a sealed version to cover an additional vulnerability that was either out of scope or not yet known when the previous sealed version was published.

Each sealed version is cumulative: `-sp2` closes everything `-sp1` closed plus whatever drove the new sealed version; `-sp3` closes everything `-sp2` closed plus more, and so on.

## Private versions

In rare cases, a vulnerability cannot be fully patched without affecting some edge cases. These cases are uncommon overall, but customers with a broad open-source footprint encounter them from time to time. Seal does not release these versions on the platform automatically, because customers need to be informed about potential side effects and should thoroughly test the updated version.

A private version is used only where a Seal Project has explicitly enabled it, so that customers are aware of the possible implications before they adopt one. Private versions are identifiable by a `p[N]` suffix on top of the sealed version. For example, if the public version is `ejs@2.7.4-sp2`, the private version would be `ejs@2.7.4-sp2p1`, `ejs@2.7.4-sp2p2`, and so on.

See [Private versions](/discovering/private-versions.md) for the chapter that covers the workflow.

## Related

* [Per-ecosystem nuances](/reference/naming-and-versioning/per-ecosystem.md)
* [Renamed packages](/reference/naming-and-versioning/renamed-packages.md)
* [Private versions](/discovering/private-versions.md)