Recommended approach for managing imported versioned schema?

[rly]

I have two applications (JAMOv2, NWB) where users write their own LinkML schemas that extend a base schema (using is_a to subclass classes). The base schema is versioned via the version field.

User schemas import the base schema by URI:

imports:
  - https://example.org/base_schema

which is resolved via an importmap in Python (SchemaLoader(schema_dict, importmap=...)) or on the CLI.

The base schema will evolve over time and may include breaking changes. My concern is: if a user writes a schema against v1.0.0 of the base, and we later publish v2.0.0 with breaking changes, the user's schema silently breaks because the unversioned URI now resolves to the new version.

Would you recommend versioning the URI (e.g., https://example.org/base_schema/1.0.0) so that old extensions remain valid? Since version strings should use semantic versioning, would a specification that supports a range of versions be better, e.g., >= 1.0.0, < 2.0.0? Is there an idiomatic way to handle this in LinkML?

[matentzn]

Would you recommend versioning the URI (e.g., https://example.org/base_schema/1.0.0) so that old extensions remain valid?

In my mental conceptual model we should organise linkml schema development using a similar system as we do using the https://github.com/INCATools/ontology-development-kit. So:

1. you have your local schema, and imports schema x - where x is a versionless schema identifier.
2. The base schema imports x from a local mirror of the x schema, for example, downloaded on 19th March 2026. That mirror is SOT.
3. Upgrading the base has to be done explicitly by running something like "just update-schema-x". This copies, downloads, pulls the extended schema from wherever its SOT is into the local workspace
4. The above can be, if the schema stewards wants, as a GitHub action that (1) performs 3 on a regular basis and (2) runs all QC checks against that new base.

Now I am not sure how @dalito, @sierra-moxon and @cmungall thought of this, and how much of this is supported - I just believe this is the right and most reslient pattern based on 8 years of doing ontology dependencies this way.

[rly]

Thanks for your response @matentzn! My use case might be a bit different because the extensions I work with are published to a catalog for others to use, so they need to remain usable over time without the extension author intervening.

Ideally, an extension documents the version (x.y.z) of the base schema it was developed against. If the base schema follows semantic versioning, there's an implicit guarantee that all base schema versions with the same major version x are compatible with the extension.

In your example, if the import statement uses a versionless schema identifier, then a user of the extension might resolve it to a newer, incompatible version of the base schema, and they'd have no way to know which versions are actually compatible. Without that information, they can't recover a working configuration on their own.

I am imagining a solution similar to how Python packages declare dependency version ranges (with all the problems that entails).

Does this scenario come up in your work? If so, how do you handle versioning for those?