Add issue_tracker field to provider model

[ml-evs]

This PR begins tracking changes to the specification beyond v1.0. We may consider maintaining this as a separate branch, or versioning our models in another way (see #609).

• Added issue_tracker field for providers, closes Incoming model update (new field: issue_tracker) #592

[codecov]

Codecov Report

Merging #593 (78eb2e2) into master (513d5b8) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #593   +/-   ##
=======================================
  Coverage   92.69%   92.69%           
=======================================
  Files          67       67           
  Lines        3752     3753    +1     
=======================================
+ Hits         3478     3479    +1     
  Misses        274      274           

Flag	Coverage Δ
project	92.69% <100.00%> (+<0.01%)	⬆️
validator	92.69% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
optimade/server/config.py	91.20% <ø> (ø)
optimade/__init__.py	100.00% <100.00%> (ø)
optimade/models/optimade_json.py	95.78% <100.00%> (+0.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 513d5b8...78eb2e2. Read the comment docs.

[ml-evs]

I'm considering splitting this PR into "fixes" and "features" following the comments around maintaining two parallel releases of the specification. We should have a discussion about how we want to version our models in the future.

Is the API stable enough to be able to pluck the models out into a separate repository where they can be versioned as releases, or does this add too much overhead on what will hopefully be fairly static objects? [additionally two model versions could not be used simultaneously with this approach]

Should we explicitly add logic for versioning models in this package, e.g. extend OptimadeField to include some kind of "supported versions" attribute per field, so that different implementations can be validated (for example) with different model versions?

I'll raise an issue on this.

[CasperWA]

Yay :)
However! We should probably change our "supported specification version" to v1.0.0~develop?

Indeed, this version splitting may pose some problems, as I believe you also point out?

[ml-evs]

Indeed, this version splitting may pose some problems, as I believe you also point out?

Yeah, I think this is blocked until we discuss #609 (and discuss spec versioning in the meeting today).

[ml-evs]

As it looks like OPTIMADE 1.0.1 will not exist, we need to update our package to the imminent 1.1.0 and fix our descriptions. I think I have done this in a10e6bb

[ml-evs]

This also sets off a cascade of schema updates (that we already tried to pre-empt for v1.0.1...). We will need to make a PR with these schemas into the spec repo before v1.1.0 can be released.

[CasperWA]

Didn't know we hadn't included issue_tracker yet 😮

[CasperWA]

Final suggestion - also, is there not also a test config file to add issue_tracker to, or maybe it doesn't really matter...?

[CasperWA]

Get in!