Proposal for triple-track versioning

[michielbdejong]

I would like to invite a discussion about triple-track versioning: the spec is one track, the apps are a second one, and the identity&storage servers a third one.

I thought this through and came to the following proposal:

• the spec is a living document that evolves. Its dependencies are also constantly evolving
• sometimes, a version of the spec is released. The last time this happened was with v0.9.0, on 17 December 2021.
• as soon as the spec is released, it's unavoidable that all members of the other two tracks (apps and servers) are considered "outdated" if they don't follow that version of the spec. So the last published version of the spec is always the version that all apps and servers should follow in production.
• When the spec or one of its dependencies evolves, apps and servers can start supporting the new functionalities, as long as the changes are non-breaking. I.e., apps and servers should never violate the latest published version of the spec, even if it, or its dependencies have since evolved.
• A bit of terminology: There are two ways for a spec document to link to another spec document: pinned and unpinned. A pinned link will forever link to the same version of the other doc (generally, the latest version at the time of creating the pinned link). An unpinned link will link to whatever the current latest version of the other document is.
• The Solid spec contains a number of unpinned links. When interpreting these, we use the WayBackMachine or some other tool to find the version of the dependency that existed when the spec was published. So for instance, v0.9.0 of the Solid spec links to the a5a966c version of solid-oidc which links to version 04 of DPop. Therefore, servers should continue to support DPop version 04 in production, and only follow the latest version of DPop if this doesn't clash with the support for its version 04.
• apps and servers should still adhere to v0.9.0 in production
• apps and servers should support previous versions in production unless it clashes with the requirement to support the latest released spec version
• apps and servers should try to support newer versions in production unless it clashes with the requirement to support the latest released spec version

And now the role of the test suite panel in this:

• We should try to offer tests for the previous, current, and (anticipated) next spec versions.
• The tests for the next spec version are likely to evolve at any time, whenever news becomes available about what the next spec version will look like.
• We should help app developers to test their app for compatibility with the previous, current, and (anticipated) next spec versions. Since our tests test servers and not apps, the best way to do that is by pointing developers to versions/configs of servers that we think support each of these versions.
• We should help server developers to test their server for compatibility with the previous, current, and (anticipated) next spec versions.
• Currently, that means (to our latest knowledge, this is subject to updates):
  • v0.8.0 (where ath was not yet required in DPop and PATCH still used sparql-update)
  • v0.9.0 (with ath required in DPop and PATCH using text/n3)
  • v"next" (with requirement to support both secure and insecure websockets)
• When v"next" becomes current, we should publish tests for the next v"next", where support for insecure websockets will be dropped, and possibly other new developments, etc.

[melvincarvalho]

It might be nice to allow ws:// for local testing?

[michielbdejong]

Working on this in solid-contrib/solidservers.org#9