4. Versioning and release cadence

Local snapshot only. The workspace page is authoritative.

4.1 Semantic Versioning

Published PDS packages use Semantic Versioning unless an explicitly approved prerelease rule says otherwise:

• Patch: backward-compatible defect correction with no public-API break.
• Minor: backward-compatible functionality, new public API, new component, or deprecation notice.
• Major: removal, incompatible behavior, public-API break, or other consumer migration requirement.
  Every merged user-facing change declares its release impact. Public API includes published component APIs, supported token identifiers and meanings, generated assets intended for consumers, and other contracts explicitly documented as supported.
  The PDP engineering lead owns technical SemVer classification. The affected design and accessibility domains must still issue go decisions when the release changes their governed behavior or evidence.
  This contract is the PDS adaptation already established from Polaris, Spectrum, and Atlassian. (Polaris, Spectrum, Atlassian)

4.2 Normal release authority

There is no universal Design Ops publication sign-off.
For each release, the PDP engineering lead identifies the affected domains with the Design Ops Lead and records the required gates. The release proceeds only after every affected domain says go. The PDP engineering lead then executes or delegates package publication and confirms the result in the release record.
Typical required gates are:

• Engineering: code, tests, dependencies, package integrity, SemVer, build, and distribution.
• Design: behavior, design quality, content, Figma parity, or token semantics when changed.
• QA/accessibility: only when the change requires evidence within borrowed QA/SDET’s accepted scope.
• Governance: Core classification, lifecycle status, support posture, or deprecation action when changed.
  A domain not affected by the change is not required to approve it. The release record must state why each domain was included or excluded.

4.3 Merge and publication separation

Merge and publication are separate controlled actions.

• A contributor opens and updates the pull request but cannot merge it.
• The PDS Lead Maintainer or named delegate merges only after the contribution-acceptance requirements in section 3 pass.
• A merged change waits for the governed release process and does not become a published consumer contract merely because it exists on the default branch.
• Only the PDS Lead Maintainer or a delegate explicitly authorized for release may execute publication.
• A contributor may prepare release notes, migration guidance, or release artifacts, but preparation does not grant release authority.
  Danielle remains the principal FY27 technical reviewer and release owner. Delegation should be used to preserve continuity and distribute bounded review work, not to transfer the engineering domain gate by implication.

4.4 Emergency engineering fixes

An authorized engineer may release an emergency patch without prior standing-working-group review only when all of the following are true:

• the issue is a confirmed production defect or security/accessibility regression;
• both the defect and the fix fall entirely within engineering’s domain;
• the change is patch-only and backward compatible;
• required automated engineering checks pass;
• the engineer accepts accountability for the technical go.
  The engineer must inform the standing working group, record the exception and affected consumers, and complete the missing documentation or retrospective review in the next working cycle.
  A design defect is not eligible for this unilateral engineering path. It is raised as a priority bug and requires the design-quality gate. A cross-domain emergency requires every affected domain’s go before release.

4.5 Deprecation and removal contract

Deprecation is announced in a backward-compatible minor release. The notice must:

• identify the affected API or asset;
• state why it is deprecated;
• stop recommending new adoption;
• name the supported replacement;
• provide migration guidance;
• state the intended removal version or date.
  Removal occurs only in a major release after the stated notice and migration requirements are met. The exact support window and notice duration are not assumed until the supported-version policy is approved.

4.6 Extended compatibility

Published Core APIs and tokens are compatibility contracts for registered Extended consumers. PDS applies SemVer, deprecation notice, and migration guidance to those Core contracts. Product teams remain responsible for updating or repairing their Extended implementations unless the intake record assigns a higher PDS support level.
PDS does not guarantee compatibility with unregistered private implementations. Core release review must use the known Extended-component registry and available consumer evidence; it must disclose when consumer coverage is incomplete.

4.7 Release record and communication

The repository changelog or release-notes page is the authoritative release record. Every release records:

• version and date;
• change type;
• affected components, tokens, or APIs;
• maturity or support changes;
• deprecations and removals;
• required consumer actions and migration guidance;
• evidence and decision-record links.
  Chat, email, office hours, and sprint demonstrations may point to the release record. They do not replace it. Sprint demonstrations communicate progress and learning, not formal release state.

4.8 Open release decisions

Open — pending Core team: package/maturity and release-channel mapping. Inventory the current versions and channels with engineering, then decide how Alpha, Beta, and Stable map to package versions, prerelease tags, separate packages, or metadata.
Open — pending Core team: supported versions and upgrades. Decide how many versions PDS supports concurrently, when support ends, who upgrades product applications, what migration assistance PDS provides, and the applicable deprecation/support period.
Open — pending Core team: release cadence. Decide whether ready changes ship continuously, at a recurring review point, or on another schedule, including the urgent-release service expectation.
Open — pending Core team: distribution architecture. Confirm current Artifactory, OCP migration, GitHub Actions, registry, credentials, repositories, publication ownership, and consumer install paths before selecting or changing the distribution pipeline.
Open — pending Core team: announcement channel. Decide whether Teams, Slack, email, or another channel carries release notifications, who owns the message, and which audiences receive it. The repository release record remains authoritative regardless of channel.