Temporarily restrict dandischema requirement to `< 0.10.2`

[jwodder]

Per @jjnesbitt's advice here

Note that I have added the "release" tag to this PR in order to get this restriction out to users soon.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.58%. Comparing base (e2d963d) to head (ccf4329). Report is 60 commits behind head on master.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1458 +/- ## ========================================== + Coverage 88.45% 88.58% +0.12% ========================================== Files 77 77 Lines 10535 10535 ========================================== + Hits 9319 9332 +13 + Misses 1216 1203 -13 ``` | [Flag](https://app.codecov.io/gh/dandi/dandi-cli/pull/1458/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=dandi) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/dandi/dandi-cli/pull/1458/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=dandi) | `88.58% <ø> (+0.12%)` | :arrow_up: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=dandi#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[github-actions[bot]]

:rocket: PR was released in 0.62.3 :rocket:

[yarikoptic]

Thank you @jwodder !

We really should see if we could somehow reduce such close tie to metadata library in terms of versioning. Hopefully having model expressed as linkml would provide us a remedy so that we could just use corresponding version of the model (like now could be done with jsonschema serialization) supported/requested by the server. Right @candleindark ?

[candleindark]

Thank you @jwodder !

We really should see if we could somehow reduce such close tie to metadata library in terms of versioning. Hopefully having model expressed as linkml would provide us a remedy so that we could just use corresponding version of the model (like now could be done with jsonschema serialization) supported/requested by the server. Right @candleindark ?

I am not sure LinkML can solve the particular problem we are facing. The current problem is that the GUI is not accepting the new generated JSON schema generated from Pydantic models. If we have the models expressed in LinkML, the JSON schema will be generated from these models expressed in LinkML instead. You will still have to test the JSON schema against the GUI.

[yarikoptic]

I meant more of being able to test against specific version of schema. We already have jsonschema dumps in https://github.com/dandi/schema/tree/master/releases so in principle, anything which relies on jsonschema alone and is fully compatible with it -- should be able to validate even against versions it didn't see yet before. But with pydantic we cannot really load/use different versions of schema, only "current one", hence rely on "most recent one" and upgrades into it.

[candleindark]

I meant more of being able to test against specific version of schema. We already have jsonschema dumps in https://github.com/dandi/schema/tree/master/releases so in principle, anything which relies on jsonschema alone and is fully compatible with it -- should be able to validate even against versions it didn't see yet before. But with pydantic we cannot really load/use different versions of schema, only "current one", hence rely on "most recent one" and upgrades into it.

Yes, in principle that should work. In the backend, assuming you are still using Pydantic models, generated from LinkML, you will need to load different versions of these models from different versions of LinkML schema.