REL-003-JAVA

Java Patch Version Naming

Java patched releases use a version naming profile that optimizes Maven, Gradle, repository-manager, dependency-update, SCA, feed, and policy-tool behavior for the affected upstream version line.

Status: Ratified
Version: 0.1.0
Pack: OSERA-SP-0.1.0 ratified
Ratified: 2026-09-10
Fitness: Required Java profile check
Category: Release Process
Applies to: Java package patch providers, Enterprise Java recipients, Java repository and dependency tooling
Extends: REL-003
Machine-readable: YAML / JSON

Relationship to parent

This profile extends REL-003 version 0.1.0. The tables are generated from the parent and profile metadata. Overrides specialize the parent obligation; inherited items apply unchanged.

Requirements

Parent item	Treatment	Effective item	What changes or remains
REL-003.REQ-001	Overrides	REL-003-JAVA.REQ-001	Specializes the generic applicable-profile rule with a Java-specific version convention. The CARE-style convention uses the OSERA identifier; the parent obligations to identify the latest applicable remediation on the same upstream line and preserve baseline and OSERA identity remain.
REL-003.REQ-002	Overrides	REL-003-JAVA.REQ-002	Specializes the parent identifier-consistency obligation for Java artifacts by explicitly including Maven package URLs. The same patched-release identity must still connect source tags, artifacts, feeds, and evidence.

Checks

Parent item	Treatment	Effective item	What changes or remains
REL-003.CHECK-001	Overrides	REL-003-JAVA.CHECK-001	Replaces generic profile-selection evidence with Java profile-decision, resolver, and dependency-update compatibility evidence. The parent consumer outcome remains the acceptance criterion; the naming convention is the CARE-style OSERA form described below.
REL-003.CHECK-002	Overrides	REL-003-JAVA.CHECK-002	Uses Maven package URL evidence for the parent consistency check while retaining release-tag, artifact-version, and feed identity matching.

Structured Requirements

REL-003-JAVA.REQ-001 MUST partially-automated

Official OSERA Java patched releases must use the ratified Java patch CARE-style version naming convention with the OSERA identifier, so supported Java resolver, dependency update, repository manager, SCA, feed, and policy tooling treats the patched artifact as the latest applicable remediation on the same upstream version line.

Check	Severity	Evidence
REL-003-JAVA.CHECK-001 Java patch version pattern passes supported tooling compatibility tests	blocking	release_tag, artifact_version, java_profile_decision, resolver_test_result, dependency_update_test_result

REL-003-JAVA.REQ-002 MUST automated

Java release tags, artifact versions, Maven package URLs, vulnerability feeds, and release evidence must carry the same Java patch version identifier.

Check	Severity	Evidence
REL-003-JAVA.CHECK-002 Java release identifier is consistent across source, artifact, and feeds	blocking	release_tag, artifact_version, maven_purl, feed_purl

Java naming convention

OSERA-SP-0.1.0 adopts Maven Central’s CARE versioning approach, using osera in place of care. The decision was agreed at the September 10, 2026 meeting and recorded in issue #33. Initial compatibility findings informed the decision; detailed findings will be published separately.

The full CARE policy describes numeric-base versioning, an alternate suffix for qualified bases, and tooling-driven deviations. OSERA adopts that approach for Java in 0.1.0, rather than imposing one concatenation rule on every historical version shape. Keep the baseline recognizable, identify OSERA, avoid taking the upstream maintainer’s next ordinary version, and validate ordering and resolution in the relevant tooling. Producer identity belongs in release metadata. The care suffix itself remains reserved for Central-approved CARE releases; OSERA naming does not confer Central publication approval.

Examples by packaging scenario

These examples illustrate the adopted approach. Validate compatibility for the actual packaging before publication.

Scenario	Upstream baseline	Illustrative OSERA version	Interpretation
Qualified Maven artifact	`5.6.15.Final`	`5.6.15.Final-osera-00001`	Retains `Final` and applies the CARE alternate suffix with `osera`.
Qualified service release	`2.0.0.RELEASE`	`2.0.0.RELEASE-osera-00001`	Keeps the upstream qualifier visible.
OSGi bundle, numeric base	`5.3.39`	`5.3.39.1-osera-00001`	The fourth component, `1-osera-00001`, is the OSGi qualifier.
OSGi bundle, existing qualifier	`1.2.3.Final`	`1.2.3.Final-osera-00001`	Extends the existing fourth-component qualifier.

OSGi versions have three numeric components and an optional fourth qualifier containing letters, digits, underscores, or hyphens; a dot cannot appear inside that qualifier. See the OSGi version grammar. Thus Bundle-Version: 5.3.39.1-osera-00001 is syntactically valid, but appending another dotted segment to an already qualified OSGi version is not. OSGi compares the qualifier lexically; syntactic validity alone does not establish update ordering. Check the actual bundle manifest, Maven coordinate, and resolver behavior together, especially when a packaging tool normalizes versions.

Consistent release identity

For a numeric-base Java release:

Upstream version: 5.3.39
Source branch:    patch/5.3.x
Baseline tag:     v5.3.39+patch.baseline
Release tag:      v5.3.39.1-osera-00001
Artifact version: 5.3.39.1-osera-00001
Maven purl:       pkg:maven/org.springframework/spring-core@5.3.39.1-osera-00001

The v prefix identifies the source tag; the artifact version and purl use the same release identifier without that prefix. Feed entries must use the exact published coordinate. Consumers adopt the explicit patched version through their dependency declaration, BOM, version catalog, or update workflow; repository priority alone does not change a dependency pinned to the upstream version.

Java uses this profile instead of the generic +osera-patch.NNN default. The meeting adopted CARE-style naming for 0.1.0; it did not adopt a dual-format experiment.

Requirement

REL-003-JAVA extends REL-003 for Java package artifacts.

Java releases MUST use the profile’s selected version pattern. Release tags, artifact versions, Maven package URLs, vulnerability feeds, and release evidence MUST identify the same patched release.

REL-003-JAVA.REQ-001 and REL-003-JAVA.CHECK-001 specialize the base naming rule for Java. REL-003-JAVA.REQ-002 and REL-003-JAVA.CHECK-002 specialize the consistency rule with Maven package URL evidence. Same-number profile checks override base checks; additional Java checks start at REL-003-JAVA.CHECK-003.

Source branch naming follows FORK-002, and baseline tags follow FORK-003.

Compatibility evidence

The Java profile gate SHOULD record evidence that the selected pattern:

resolves as a distinct patched artifact;
sorts or is recommended after the vulnerable upstream version where Java tooling supports that behavior;
remains visibly tied to the upstream baseline version;
is preserved in Maven package URLs and feed records;
can be discovered by supported dependency-update workflows;
does not consume the upstream maintainer’s next ordinary release version.