Versioning and Release Policy

The Galileo Luxury Standard uses Semantic Versioning with extended deprecation timelines reflecting luxury product lifecycles, where products have multi-generational lifecycles and adopters require exceptional stability guarantees.

1. Version Format

The Standard uses Semantic Versioning 2.0.0 (SemVer):

MAJOR.MINOR.PATCH

MAJOR— Breaking changes (backward-incompatible). Examples: field renamed, required field removed, semantic change.
MINOR— New features (backward-compatible additions). Examples: new optional field added, new endpoint.
PATCH— Bug fixes and clarifications (no functional change). Examples: typo correction, documentation clarification.

Pre-release Versions

1.0.0-alpha.1    # Early development, unstable
1.0.0-beta.1     # Feature complete, testing
1.0.0-rc.1       # Release candidate, final validation

Pre-release versions are not covered by deprecation guarantees, may contain breaking changes, and should not be used in production implementations.

2. What Constitutes a Breaking Change

A breaking change is any modification that would cause a previously-conformant implementation to become non-conformant.

Breaking Changes (Require MAJOR Version)

Field removal or rename
Semantic change (e.g., changing date format)
Type change on existing field
Validation tightening on existing fields
Enum restriction (removing values from closed enumeration)
Endpoint removal or authentication change
Protocol change (transport or encoding)

Non-Breaking Changes (MINOR or PATCH)

Adding optional fields or endpoints (MINOR)
Extending open enums (MINOR)
Relaxing validation (making required field optional) (MINOR)
Documentation clarifications, typo corrections (PATCH)

3. Release Schedule

Semiannual Cadence

Minor releases— Semiannual (March and September). New features and improvements.
Patch releases— As needed, typically monthly. Bug fixes and clarifications.
Major releases— Only when necessary, with minimum 60-day RFC review. Breaking changes.

Semiannual Schedule Rationale

The March/September cadence provides:

ERP integration predictability— Enterprise adopters can plan integration work around known release dates
RFC consensus time— Sufficient time to gather feedback from diverse stakeholders
Industry alignment— Avoids major fashion industry events (Fashion Weeks, SIHH, Baselworld)
Testing windows— Allows thorough validation before adoption

Release Timeline

T-8 weeks    RFC submission deadline for inclusion
T-4 weeks    Feature freeze (no new features accepted)
T-2 weeks    Release candidate published
T-0          Final release published

4. Breaking Change Process

Breaking changes are taken seriously because they affect every implementor. The process requires:

An RFC for each breaking change with a minimum 60-day review period
TSC veto rights apply— Any TSC member may exercise a veto on proposed breaking changes (see the Governance Charter Section 6)
A comprehensive migration guide with code examples, prepared at least 30 days before release
An extended release candidate period (4 weeks) with active outreach to major adopters

5. Deprecation Policy

10-Year Sunset Period

Deprecated features have a 10-year sunset period from the deprecation announcement date.

Rationale: The luxury goods industry operates on timescales incompatible with standard software deprecation practices:

Fine watches are passed between generations
Jewelry pieces may be held for 50+ years
Heritage leather goods appreciate with age
Wine and spirits may be cellared for decades

During the Sunset Period

Feature remains fully functional
Documentation maintained
Security fixes and bug fixes provided
No new features for deprecated components

After sunset, the feature may be removed in the next MAJOR release. Documentation is archived but available.

Deprecation Notification Schedule

At deprecation— Full documentation, migration guide, sunset date stated
5-year notice— Reminder notification, migration resources
2-year notice— Escalated notice, migration support offered
1-year notice— Final migration planning window
6-month notice— Urgent migration reminder
3-month final warning— Last call, removal imminent

6. Security Hotfixes

72-Hour Coordinated Disclosure

Critical security vulnerabilities receive expedited handling with a 72-hour coordinated disclosure window.

T-0h     Vulnerability reported to security contact
T+4h     Initial triage and severity assessment
T+24h    Fix developed and tested (if critical)
T-72h    Private notification to known adopters
T-48h    Patch release prepared
T-24h    Final testing
T-0h     Public release and advisory

Severity Response Times

Critical (CVSS 9.0–10.0)— 72-hour coordinated disclosure
High (CVSS 7.0–8.9)— 7-day coordinated disclosure
Medium (CVSS 4.0–6.9)— Next patch release
Low (CVSS 0.1–3.9)— Next minor release

Report vulnerabilities to: security@galileoprotocol.io

7. Long-Term Support (LTS)

The last minor release of each MAJOR version receives LTS status:

Security fixes for the full 10-year sunset period
Critical bug fixes for 5 years
Documentation maintained for 10 years

8. Backward Compatibility

Forward compatibility: Newer versions can always read data created under older versions of the same MAJOR release.
Unknown field handling: Implementations MUST NOT reject documents containing unknown fields. Unknown fields SHOULD be preserved in round-trip scenarios.
A conformant implementation MUST support the current MAJOR version and SHOULD support the previous MAJOR version during its sunset period.