> 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/legacy-documentation/versioning-schema.md).

# Versioning Schema

### Package Renaming

When we remediate a package, we offer two naming conventions:

1. **Original Alternative**: Retain the original package name and simply update the version.
2. **Renamed Alternative**: Change both the package name and version to indicate the package is a fork created by Seal Security.

This choice allows flexibility depending on whether the customer wants to have the original package name or not in their Software Bill of Materials (SBOM).

<table data-full-width="true"><thead><tr><th width="148.7406005859375">Ecosystem</th><th width="178.4814453125">Package Name in Original Alternative</th><th width="170.4444580078125">Version in Original Alternative</th><th width="253.8887939453125">Package Name in Renamed Alternative</th><th width="303.0955810546875">Version in Renamed Alternative</th></tr></thead><tbody><tr><td>Java</td><td>$groupId:$artifactId</td><td>$version<strong>+sp$X</strong></td><td><strong>seal.sp$X.</strong>$groupId:$artifactId</td><td><p>$version</p><p>(removes +sp$X; +sp999 may be added as sentinel in fixed events)</p></td></tr><tr><td>Javascript</td><td>$name</td><td>$version<strong>-sp$X</strong></td><td><strong>@seal-security/</strong>$name</td><td>$version<strong>-sp$X</strong></td></tr><tr><td>Javascript (scoped)</td><td>@$scope/$name</td><td>$version<strong>-sp$X</strong></td><td><strong>@seal-security/$seal-</strong>$name</td><td>$version<strong>-sp$X</strong></td></tr><tr><td>Python</td><td>$name</td><td>$version<strong>+sp$X</strong></td><td><strong>seal-</strong>$name</td><td>$version<strong>+sp$X</strong></td></tr><tr><td>Go</td><td>$name</td><td>$version<strong>-sp$X</strong></td><td><a href="http://sealsecurity.io/$name"><strong>sealsecurity.io/</strong>$name</a></td><td>$version<strong>-sp$X</strong></td></tr><tr><td>Ruby</td><td>$name</td><td>$version<strong>.0.1.sp$X</strong></td><td><strong>seal-</strong>$name</td><td>$version<strong>.0.1.sp$X</strong></td></tr><tr><td>Debian</td><td>$name</td><td>$version<strong>+sp$X</strong></td><td><strong>seal-</strong>$name</td><td>$version<strong>+sp$X</strong></td></tr><tr><td>RPM</td><td>$name</td><td>$version<strong>+sp$X</strong></td><td><strong>seal-</strong>$name</td><td>$version<strong>+sp$X</strong></td></tr><tr><td>Alpine</td><td>$name</td><td>$version<strong>-r$REV</strong></td><td><strong>seal-</strong>$name</td><td>$version<strong>-r$REV</strong></td></tr></tbody></table>

### Private Versions

In rare cases, a vulnerability can't be fully patched without affecting some edge cases. These instances are uncommon, and most customers don't encounter them. However, we can't freely release these versions on the platform, as customers need to be informed about potential side effects and should thoroughly test the updated version.

We manually enable the use of private versions to ensure customers are aware of possible implications. Private versions are identifiable by a **pN** suffix in their version number. For instance, if the public version is `ejs@2.7.4-sp2`, the private version would be labeled `ejs@2.7.4-sp2p1` or `ejs@2.7.4-sp2p2`, etc.