Version 1.1 should be 2.0

[romgrk]

Hey,

So I was reading the spec and I was wondering why it was incremented to 1.1 from 1.0? If I read #81 correctly and I understand what a breaking change means, it should have been incremented to 2.0. Am I reading things wrong?

Also instead of coming up with a custom versionning scheme wouldn't it be nice to use the more standard semver?

Thanks,

[sitag]

@romgrk short answer:consortium decision. @dbujold is your best source for everything that isn't really an operational technical issue.

[dbujold]

Hi Sita, sorry for jumping in the conversation that late, could you provide a link to the thread on the string to 1-element-array decision? Thank you,

David

[sitag]

@dbujold It's the email thread titled "prevalidation." You are on it. Recall the behavior without arrays is incorrect because we drop everything after the first element when things are not arrays (this actually goes back years); so there's no going back here.) Also, from call either in feb or jan, semantic versioning was not opted into.

[romgrk]

@sitag but semver or not, labeling what is called version 1.1 as 1.1 is wrong according to the versioning scheme that is described in this spec. Isn't it?

My point is just that in my understanding, the version for that one should be 2.0.

[sitag]

@romgrk I was involved with neither.

[sitag]

@romgrk what broke?

[romgrk]

Using the new schema with old datahubs obviously won't work because of the length-1 arrays.

[sitag]

@romgrk The json schema is not the spec. It's the implementation of the spec. It's also not a complete implementation.

[dzerbino]

Hello @romgrk ,

To answer your original question, what basically happened is that we named the version 1.1 before all the changes were in. In hindsight, 2.0 might be more appropriate. As Sita says earlier, it is still work in progress.

In our now SOP (i.e. for next time) we will call the new spec dev until it is adopted: https://github.com/IHEC/ihec-ecosystems/blob/master/SOP/Schema_updates.md

Overall, this whole lesson has taught us that we need to tighten our processes, as too much of the background knowledge is scattered across people and e-mail threads, and thus contributors naturally make mistakes (as I have) or get confused (as you did).

However, we have also learned that JSON schemas are insufficient in many ways (we're not the only consortium to enrich JSON schema with extra code), which means that at moment you cannot expect the JSON to be the be all end all of our spec.

Hope this helps,

Daniel

[sitag]

@dzerbino I think this is little subtle. @romgrk wants the spec to be called 2.0 because adding arrayed elements make the jsonschema incompatible with what it was before. Adding the array type instead of simple type has no bearing on what is the spec. The spec describe the metadata that must be present, the jsonschema is how it must be structured. Changes to jsonschema are not changes to the spec.

The change is still a breaking change because now between 1.0 and 1.1 because we go from using URIs to CURIEs so metadata that is 1.0 is not necessarily 1.1. So the 2.0 instead of 1.1 is still a valid question.

[dzerbino]

As discussed today by phone, we will update the version number from 1.1 to 2.0.