Are spec dependencies assumed to be pinned?

[michielbdejong]

Version 0.9.0 of https://solidproject.org/TR/protocol was last modified on 17 December, but if you follow the link from there to the Solid OIDC spec, that is an unversioned link to https://solid.github.io/solid-oidc/

That document claims to have been created on 28 April which is odd in itself because on 13 December https://github.com/solid/solid-oidc/tree/a5a966c7342da01a57bfb316e5533ea7d82fd245 already pointed to it. In any case, it seems likely that at the time of publishing, version 0.9.0 of the spec pointed to this version of Solid OIDC, which in turn points to version 4 of the DPoP id.

Readers who read version 0.9.0 of the Solid spec nowadays, and follow their nose, end up at https://solid.github.io/solid-oidc/#normative which points to DPoP without choosing any particular version.

In software development it's common practice to pin dependencies when publishing. This prevents things from breaking at random unexpected times, and allows the publisher to update dependencies in a controlled way. Should we do the same in spec development?

[csarven]

I believe the dates of the Solid-OIDC ED: https://solid.github.io/solid-oidc/ , should be as suggested as in #105 (comment), in particular:

And for ED (example path):

ED/oidc

• Created: 2021-07-16 (whenever it came to existence)
• Published: 2021-07-16 (usually same as created...)
• Modified: 2022-04-30 (update as you go)

Note that above I used the date from gh-page's first commit - assuming everything else was configured for https://solid.github.io/solid-oidc/

[elf-pavlik]

Since FPWD was released to https://solidproject.org/TR/oidc no releases should point anymore to the ED.

@michielbdejong any version release of Solid-OIDC will be now processed with this github workflow https://github.com/solid/solid-oidc/blob/main/.github/workflows/tr-draft-config.yml

There result will go as PR to https://github.com/solid/specification

[csarven]

Since FPWD was released to https://solidproject.org/TR/oidc no releases should point anymore to the ED.

That is at the discretion of the authors making the citation.

TR/protocol as of this writing refers to Solid-OIDC ED, and ED/protocol (will eventually make it into the next update of TR/protocol) refers to TR/oidc. The Solid-OIDC ED dates should be corrected irrespective to any of that.

[acoburn]

Just as in software development, when referencing a "snapshot dependency" (in this case, that would be an editor's draft), you need to be aware that this dependency may change at any time.

It is true that Solid Protocol 0.9 points to the editor's draft of Solid OIDC, which means that the dependency is not fixed.
You will also note that the published Solid-OIDC 0.1 document depends on the draft DPoP specification (which also continues to change)

Obviously, it is better for a published specification to always depend on other non-draft published specifications, but that is not always possible. (WebID has been in draft since 2005). In this case, if the dependency is a draft, there is an implicit acknowledgement that the dependency is not fixed

[elf-pavlik]

In software development it's common practice to pin dependencies when publishing. This prevents things from breaking at random unexpected times, and allows the publisher to update dependencies in a controlled way. Should we do the same in spec development?

@michielbdejong does described workflow, starting from Solid-OIDC 0.1, satisfy your suggestion?

The Solid-OIDC ED dates should be corrected irrespective of any of that.

@csarven could you please submit a PR that corrects the dates?
Otherwise at least please explain here which exact dates you would like to be changed, including expected values.

[csarven]

Update created and add published. See the suggested values as mentioned in #197 (comment).

[michielbdejong]

if the dependency is a draft, there is an implicit acknowledgement that the dependency is not fixed

That answers my question, thanks!