[INFRA] introduce versioning of the schema itself

[yarikoptic]

Note -- it is not a version of the content of the schema, it is
a version over organization of the schema (e.g. we could add some
schema to describe how schema is organized).

The 'desire' for having a version over the BIDS schema's version
is somewhat described in README.md in added section. Just to facilitate
tools to know what versions of bids schema they can read without explicitly
whitelisting BIDS versions themselves. Might become more relevant as more
versions start to appear in https://github.com/bids-standard/bids-schema

I will feel totally Ok if we just drop this PR for now entirely.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.50%. Comparing base (e140f35) to head (d29ee93).
Report is 1423 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1013      +/-   ##
==========================================
+ Coverage   70.53%   71.50%   +0.96%     
==========================================
  Files           9        9              
  Lines         930      930              
==========================================
+ Hits          656      665       +9     
+ Misses        274      265       -9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tsalo]

I think this is a great idea. From what I can tell, we have four concurrent versions we need to track in this repository:

1. the specification, which is handled outside of the schema
2. the schema structure
3. the schema contents
   • Once the schema is complete, this would march in line with 1.
4. the schemacode version, which is tracked with versioneer I think

Does that sound right? And this would track the schema structure, correct?

[yarikoptic]

Does that sound right?

pretty much. I feel that 1 and 3 are coming together, ie. I don't really see a need to separate out specification as what is outside or inside schema in respect of versioning.

code, as long as it is not distributed as a usable thing outside of this repo, is probably not worth its own versioning. But we should aim indeed to move good portion of the code outside (and thus it would get its own versioning), and leave only the code needed for specification rendering etc.

And this would track the schema structure, correct?

correct

[yarikoptic]

attn @bids-standard/schema -- I am starting the campaign to decide on the destiny of adding versioning of schema's schema! Please review/approve/request changes.

[effigies]

I'm okay with this. It would be nice if we could have some code that would allow us to identify a break, but that might be asking too much prior to the existence of a version number.

[sappelhoff]

sounds good to me, but I'd include a sentence on how the versioning changes after the 0. series (i.e., starting with 1.0.0)

[yarikoptic]

@effigies

It would be nice if we could have some code that would allow us to identify a break,

do you mean having some CI code which would identify change to schema breaking compatibility? indeed, not sure yet how we could do that programmatically.

@sappelhoff

I'd include a sentence on how the versioning changes after the 0. series (i.e., starting with 1.0.0)

I'd say that the exact approach would be worked out based on our experience with versioning the 0. series, but let's indeed verbalize what we think it would be -- proposing in https://github.com/bids-standard/bids-specification/pull/1013/files#r838758576 -- looks ok'ish?

[effigies]

@yarikoptic @sappelhoff @tsalo Our plan this week is to continue work in separate schema branches (kept synced with changes in master). By the end of the week, we will very likely have sufficient changes to justify bumping the version in some way, so I would suggest finalizing this and merging before the end of the week so that we can have a clear break in pre/post workshop.

[sappelhoff]

I'd say that the exact approach would be worked out based on our experience with versioning the 0. series, but let's indeed verbalize what we think it would be -- proposing in https://github.com/bids-standard/bids-specification/pull/1013/files#r838758576 -- looks ok'ish?

agreed, thanks for your addition. This lgtm

[yarikoptic]

@yarikoptic @sappelhoff @tsalo Our plan this week is to continue work in separate schema branches (kept synced with changes in master). By the end of the week, we will very likely have sufficient changes to justify bumping the version in some way, so I would suggest finalizing this and merging before the end of the week so that we can have a clear break in pre/post workshop.

can only wholeheartedly support the "Merge this PR" initiative! I force pushed rebase to resolve conflicts (if I got it right due to "folder" -> "directory", so I used "directory" too)