Define version scheme for purl-spec and vers-spec

[mjherzog]

We need to define the version scheme for purl-spec (with the expectation that it will also apply to vers-spec).
The default version scheme has been SemVer, but we need to discuss and confirm the desired version scheme.

Overall version scheme

For a SemVer approach, the focus would be on the specification including schemas and documentation rather than the small amount of workflow-related software (etc/scripts):

• Reserve MAJOR for breaking changes
• Use MINOR for normative changes
• Use PATCH for editorial changes (sparingly)

What are the alternatives to SemVer?

Relationship to Ecma standard editions

• What is the relationship between the PURL Ecma "edition" (Ecma terminology for version) and the broader PURL specification version scheme?
  • Do we need to reserve PURL Spec v1.1 for changes that we will likely propose for the next iteration of the PURL Ecma standard or do we use SemVer (or other scheme) for the PURL Spec separately.
  • In the latter case we could propose a new Ecma standard edition for any future version of the PURL Spec (MINOR or MAJOR) as needed so we might propose a new Ecma standard edition for PURL Spec v1.1, v1.2, etc. We would likely want to propose a new edition of the Ecma standard for any new MAJOR version of the PURL Spec.

Version scheme for PURL Type definitions

• PURL type definitions are intentionally not included in the PURL Ecma standard for many reasons including the expected volume of new PURL types and ongoing refinement of definition data for registered PURL types. Creators and users of PURL tools will want some way to track changes to PURL type definitions.
• Do we want to assign versions to individual PURL type definitions? or use a collection approach where we assign a version to a set of PURL type additions and changes? A CalVer approach might work well for versioning collections of PURL type changes.
  • Most use cases are probably for tools using the current set of all registered PURL type definitions which could be handled by a version scheme at the collection level.
  • Some use cases may be for a specific PURL type definition in which case the "user" would likely be happier with a version scheme at the PURL type level.
• If we want to assign versions to individual PURL type definitions, what is the version scheme? Using SemVer (or another scheme as defined at the PURL Spec level) might create confusion - e.g., what does it mean to have a PURL Type of v1.2.1 in the context of a current PURL Spec version of v1.1.0.
• Do we allow different PURL type definition version schemas by PURL type? For example an ecosystem might want to tie the PURL type version to MAJOR changes for that ecosystem.
• The history of changes to a PURL type definition will always be available in Git, but this could be laborious to track. Using a Git commit hash for a PURL type definition version could at least flag a difference between versions of the data.

The most urgent question is to agree on the version scheme for the PURL Spec, but we should at least have a plan for PURL type versions when we finalize the version scheme for the PURL Spec.

[pombredanne]

This looks all good to me. @mjherzog I also like the idea you floated of a calver for PURL types that we release once in a while, like once a month or a quarter, so that this is disconnected from the version of the type definition and the spec definition, and avoids confusion. Something like 25.10.04 for a release on October 4th 2025, or shorter as just 25.10 ?

[mjherzog]

During the TC54/TG2 call today there was a suggestion to use CalVer for the specification with JSON Schema - https://json-schema.org/specification-links - as an example of a specification moving from SemVer to CalVer. This is confusing as an example (beyond all versions named as "draft") because:

• Common Name: Draft 2019-09 was published: 17-September-2019, BUT
• Common Name: Draft 2020-12 was published: 16-June-2022 AND
• Common Name: Draft 2021-NN (not published)
  So we apparently have a CalVer of Draft 2020-12 for a version published in 2022 - that seems very confusing with version name apparently based on when a new version is started, not when it is published ??

Given that we do not have an established cadence for specification releases I am skeptical that CalVer makes sense for specification releases, but CalVer still makes sense for PURL Types because the release only depends on when we want to release a set of PURL type changes.