Patch Initiative Version Metadata
Patched releases use SemVer build metadata that identifies the patching initiative and release sequence.
Structured Requirements
Official OSERA patched releases must use SemVer build metadata in the form
| Check | Severity | Evidence |
|---|---|---|
|
REL-003.CHECK-001 Official release metadata uses the OSERA patch token |
blocking | release_tag, artifact_version |
Release tags, artifact versions, vulnerability feeds, and release evidence must carry the same patched-release identifier.
| Check | Severity | Evidence |
|---|---|---|
|
REL-003.CHECK-002 Release identifier is consistent across source, artifact, and feeds |
blocking | release_tag, artifact_version, feed_purl |
Requirement
Official OSERA patched releases MUST use SemVer build metadata in the form:
<UPSTREAM_VERSION>+<PATCH_INITIATIVE>.NNN
<PATCH_INITIATIVE> SHOULD identify the patching initiative, provider, or organization responsible for the patched release. For OSERA-managed releases, the candidate metadata token is:
osera-patch.NNN
NNN MUST be monotonically increasing for the same upstream version line and patching initiative.
Release tags, artifact versions, vulnerability feeds, and release evidence MUST carry the same patched-release identifier so recipients can correlate source, binary, scanner, and advisory records.
Existing OSERA backpatch repositories currently use +backpatch.NNN. The working group should treat that form as legacy/proof-of-concept evidence. Official signed artifacts claiming OSERA-SP-0.1.0 alignment MUST use +osera-patch.NNN.
This standard defines the official patched-release identity. It does not rename source workflow branches or baseline tags. FORK-002 deliberately uses patch/<version> as the source branch convention, and FORK-003 deliberately uses v<VERSION>+patch.baseline for the unpatched source baseline.
Rationale
This form preserves the upstream version while making the patched artifact distinguishable. It follows the Semantic Versioning 2.0.0 build metadata shape, where metadata is appended after + as dot-separated identifiers.
Including the patching initiative in the visible component coordinate helps SCA tools, inventories, and approval workflows distinguish OSERA-managed releases from other downstream patch providers when repository or feed metadata is not shown.
The numeric suffix keeps ordering simple for repeated releases on the same upstream version line. Some build tools may compare SemVer build metadata differently or rank 5.3.39+osera-patch.001 lower than the plain upstream 5.3.39, so consumers SHOULD pin the exact patched version rather than relying on dynamic version resolution.
Package URLs MUST encode + as %2B, for example pkg:maven/org.example/example-lib@1.0.0%2Bosera-patch.001.
Open questions before ratification
The working group still needs additional dialogue before the September 3, 2026 target decision on whether the SP-0.1.0 convention should remain pure SemVer build metadata, shift toward a Maven-style qualifier, or allow ecosystem-specific profiles.
Open questions include:
- whether SemVer build metadata or Maven qualifier ordering is better honored by Maven, Gradle, repository managers, SCA tools, and downstream policy engines;
- whether a naming model should allow the original maintainer or another upstream-compatible actor to supersede external patch releases cleanly;
- whether provider-specific patch names could distort consumer prioritization by making one producer appear to be the latest release for a shared namespace;
- how OSERA should handle large numbers of patches from different producers targeting the same artifact namespace and upstream baseline.
Examples
5.3.39+osera-patch.001
5.3.39+osera-patch.002
Observed OSERA examples
Public OSERA repositories currently include legacy/proof-of-concept +backpatch.NNN release tags such as:
backpatch-spring-framework:v5.3.39+backpatch.001backpatch-gson:v2.8.8+backpatch.001backpatch-activemq:v5.14.5+backpatch.001