FORK-002

Patch Branches

Patch providers use `patch/` source workflow branches for every supported major or minor line.

Status: Draft
Version: 0.1.0
Pack: OSERA-SP-0.1.0 candidate
Ratified: Not ratified
Fitness: Required check
Category: Fork Management
Applies to: Patch providers, OSERA maintainers
Machine-readable: YAML / JSON

Structured Requirements

FORK-002.REQ-001 MUST automated

Patch providers must create version-scoped source workflow branches using patch/.

Check	Severity	Evidence
FORK-002.CHECK-001 Supported line has a patch version branch	blocking	branch_name

Requirement

Patch providers MUST create source workflow branches using the form:

patch/<version>

The <version> segment SHOULD identify the major, minor, or maintenance line being patched.

Rationale

OSERA may patch multiple major or minor versions of a single upstream project. Version-scoped branches make the supported line explicit and avoid mixing unrelated maintenance histories.

The patch/ prefix is deliberately a source workflow convention, not the official patched-release identity. Official OSERA release tags and artifact versions are defined by REL-003 and use the +osera-patch.NNN build metadata token for signed artifacts claiming OSERA-SP-0.1.0 alignment.

The version segment in patch/<version> SHOULD correspond to the upstream version or maintained line used by the baseline tag in FORK-003 and the official patched-release identifier in REL-003.

Examples

patch/5.3.x
patch/2.7.x
patch/1.2.17

Observed OSERA examples

The public finos-osera/backpatch-spring-framework repository uses backpatch/5.3.39, and finos-osera/backpatch-logback uses backpatch/1.2.9. Those examples are legacy/proof-of-concept branches that predate this proposed standard.

Not every current OSERA repository uses this branch convention yet, so tooling should treat it as a target standard rather than an assumption about all historical repos.