Release Management and Versioning

[arnoweiss]

There's a couple of release-related issues I'm anticipating for the upcoming works.

1. artifacts: message schemas, the @context etc may require a new release and thus get new identifiers.
2. Do we need specification text in the releases folder?
3. there's files namespaced as belonging to a certain release which weren't in initially. That may motivate a new release. (see Context Schema doesn't resolve #76)

[wolf4ood]

As briefly discussed here probably a 2025/1 is needed to bring the improvements of artifacts.

I would also take the chance to fix #72 and use:

https://w3id.org/dspace/2025/1/context.jsonld

as the context URL

[arnoweiss]

Yes, that works. Currently everything that's on main deviates from the initially released specs anyway so we might as well execute the namespace change as long as the redirects for 2024/1 point to the releases folder.

[juliapampus]

Do we need specification text in the releases folder?

Every normative part of the spec (incl. text) is part of a release.

[arnoweiss]

I agree - the initial contribution however didn't include it. So baking it retroactively into the releases folder isn't in scope I think. The current deployment links to the abandoned ids-specifications repo as the source which should be ok. For the release before 2024-1 I'd have no idea where to find the spec texts.