[spec] (semantic) versioning for classes of products

[elf-pavlik]

I'm extracting it as a dedicated issue from #97

Depending on specification, sometimes classes of producs are grouped into distinct interoperability pairs, some examples

• https://solidproject.org/TR/notifications-protocol#interoperability
• https://www.w3.org/TR/fedcm-1/#introduction

FedCM makes a better example with interop between pairs

• RP <-> User Agent
• User Agent <-> IDP
• RP <-> IDP (mostly with specific auth type like IndieAuth or Solid-OIDC)

When interop within specific pair changes, and it leads to semver bump, possibly even a breaking change, the third class of products doesn't need a version bump, especially one that signals breaking change.

Most implementations don't conform to all classes of products in a spec, usually they implement one specific class of products and the whole reason of conforming to the spec is interop with other independent implementations. In that case bumping major (breaking) versions for all classes of products is miseading to the implementers.

Soon I will be implementing it in solid-efforts and will be able to provide more developer experience. As far as I know no existing software uses the design of classes of products and their versions. specification-tests and conformance-test-harness have some improvised comment in/out placeholders https://github.com/solid-contrib/specification-tests/blob/main/protocol/solid-protocol-test-manifest.ttl#L8-L15

I would like to copy over excerpt from Sarven's comment in #97 (comment)

Each specification version already has its own URI e.g., for Solid Protocol:

• https://solidproject.org/TR/2024/protocol-20240512
• https://solidproject.org/TR/2022/protocol-20221231
• https://solidproject.org/TR/2021/protocol-20211217

The last two versions (URLs ending 20240512, 20221231) defines the classes of products, e.g., https://solidproject.org/TR/2024/protocol-20240512#Server , https://solidproject.org/TR/2022/protocol-20221231#Server

I would like to see some software using those distinct IRIs for classes of products on different versions. Also currently I don't see how those specific versions relate to the unversioned class of products.

As well as compare approaches where a direct relation and URI of class of products which is for specific version is used, with approach where qualified (n-ary) relations are used with URI of unversioned class of products.

Unless examples of implementations are provided, I think we can assume that maturity of this part of the spec data model is at stage 0