Baseline Tags
Every patch line identifies its unpatched starting source SHA with a `v
Structured Requirements
Patch providers must tag the unpatched baseline source commit using v
| Check | Severity | Evidence |
|---|---|---|
|
FORK-003.CHECK-001 Baseline tag exists and resolves to a commit |
blocking | baseline_tag, baseline_commit |
Requirement
Patch providers MUST tag the commit that represents the unpatched baseline source state for a patched version.
The tag MUST use the form:
v<VERSION>+patch.baseline
This tag scheme applies regardless of the upstream project tag convention.
Rationale
Recipients need an unambiguous starting point for source comparison, provenance review, and audit evidence.
The +patch.baseline suffix is deliberately a source baseline marker. It does not identify an official patched release or artifact. Official OSERA patched releases are defined by REL-003 and use +osera-patch.NNN for signed artifacts claiming OSERA-SP-0.1.0 alignment.
The <VERSION> segment in v<VERSION>+patch.baseline SHOULD correspond to the source branch version in FORK-002 and the upstream version segment in the official patched-release identifier defined by REL-003.
Evidence
Patch evidence SHOULD include the baseline tag, the commit SHA it resolves to, and the corresponding upstream version or artifact.
Observed OSERA examples
Public OSERA repositories currently include baseline tags such as:
backpatch-spring-framework:v5.3.39+backpatch.baselinebackpatch-gson:v2.8.8+backpatch.baselinebackpatch-activemq:v5.14.5+backpatch.baselinebackpatch-logback:v1.2.9+backpatch.baseline
These observed tags are legacy/proof-of-concept evidence that predates the proposed +patch.baseline convention.