Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add version identifier #1532

Open
joostholslag opened this issue Jul 15, 2024 · 3 comments
Open

Add version identifier #1532

joostholslag opened this issue Jul 15, 2024 · 3 comments
Labels
proposal Initial discussion of a new idea. A project will be created once a proposal document is created.

Comments

@joostholslag
Copy link

joostholslag commented Jul 15, 2024

I'd love the ability to specify the version of a schema.
It should identify the version of the current schema (not of the specification/meta-schema.
It should be recommended to use semantic versioning of the schema.
Similar to OpenAPI info_object.version: https://spec.openapis.org/oas/latest.html#info-object
It would help to express openEHR archetype models for clinical data in something standard like json-schema.

It could be solve by introducing a new keyword like "version" where the value is a string with recommended formatting in "x.x.x".

p.s. I'm sorry if this has been asked and answered. a search for 'version' produced many results, the first two pages were not relevant and 'semantic version' didn't produce any relevant results.

@joostholslag joostholslag changed the title Add version identifier keyword Add version identifier Jul 15, 2024
@gregsdennis
Copy link
Member

Hey there. Thanks for the suggestion. I'm pretty sure we've received this request before, but it's really been in more of a "how do I manage my schema version?" format.

I recommend doing what we actually do with the meta-schemas: embed the version into the $id URI. This promotes schemas never changing and supports a better transition story to the new version. When you have a new version, you publish it separately with a new $id. This give the consumers of your older schema an opportunity to update to the new one.

You can still use semver in the $id if you like. With the upcoming spec release, we've settled on something like /<version-number>/<release-year>, using an integer version as a semver "major" value to indicate compatibility between releases. This allows our users to also use /<version-number> to just get the latest compatible release for the version.

I'll mark this as a proposal and leave it open to get others' opinions as well.

@gregsdennis gregsdennis added the proposal Initial discussion of a new idea. A project will be created once a proposal document is created. label Jul 15, 2024
@awwright
Copy link
Member

@gregsdennis has a good suggested alternative.

Your idea could be pursued as part of a generic mechanism for metadata (perhaps a variation on "$comment" that accepts a JSON-LD blob), but anything more specific than that doesn't make sense.

@idanidan29
Copy link

idanidan29 commented Feb 24, 2025

I like the idea of using the $id method for specifying versions, but I think we can also implement @joostholslag's idea. I've thought about it and have a suggestion that takes a slightly different direction.

Instead of adding a 'version' keyword, we could introduce a boolean like version_support: true, which would enable the $id to support special version syntax, such as latest, stable, and others. If version_support is not mentioned, it would default to false, meaning the existing $id method would continue to work.

This approach offers a more user-friendly option for version control without breaking current practices.

Example

$ref Usage:

{
  "type": "object",
  "properties": {
    "patientData": { "$ref": "https://example.com/schemas/patient-record/latest" }
  }
}

And the schema would be:

{
  "$id": "https://example.com/schemas/patient-record/1.0.0",
  "version_support": true,
  "type": "object",
  "properties": {
    "patientName": { "type": "string" },
    "patientAge": { "type": "integer" }
  }
}

I know its kinda off the main topic, but I think it takes all things into consideration, and I’d love to hear feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Initial discussion of a new idea. A project will be created once a proposal document is created.
Projects
None yet
Development

No branches or pull requests

4 participants