reconsider version binding with MMIF spec

[keighrim]

Because

The problem with SDK version, while using three digits in the version string, indeed having only one digit-space as its actual versioning scheme ("major" and "minor" digits are tied to MMIF spec version) has been raised in multiple occasions (https://github.com/clamsproject/mmif/issues/14#issuecomment-847478079, https://github.com/clamsproject/mmif/issues/228#issuecomment-2226406193) and there are more pending issues (#292 #295 #296 ) that are destined to "break" from older versions. So I don't think we can further operate under the current versioning scheme.

A few possible solutions to the problem

1. total separation of MMIF version digits and mmif-python version digits at least in formal way (we can keep some "convention" to sync up two versions to a reasonable extent)
2. use four-digit version scheme for mmif-python to give a wider room to "break" things.
3. stop "minor" digit sharing and keep three digit versioning - this is in the middle between the above two. A "minor" bump in the MMIF spec won't "break" anything (it just add more features while not changing any existing behaviors), so keeping the "major" digit sync will still indicate that all mmif-python==1.* will work with MMIF files (<2.0).

Any input is welcome. Please share your thoughts.

Done when

No response

Additional context

No response

[keighrim]

So, looping back to the "meaing" of those digits (https://github.com/clamsproject/mmif/issues/23) based on the sem-ver scheme, there are different types of changes we make to code.

1. (pb) publicly breaking changes (deletion of a public API, changes of signature or behavior of a public API, etc)
2. (pa) publicly adding changes (adding a new method, feature, etc)
3. (b) privately breaking changes (breaking changes in a private functionality of the code)
4. (a) privately adding changes (adding a private method, class, etc)
5. (f) fixing public and private bugs (https://xkcd.com/1172/)

(of course any of these types can be eventually breaking, but let's pretend we're in an ideal world)

Now, sem-ver suggests that only pb type of changes are real "breakage", so it suggests

1. major digit goes for pb changes
2. minor digit goes for pa changes
3. all other changes go with patch digit

Now applying the same to the spec, we can roughly think of

1. (spb) publicly breaking changes (deletion of a public spec, scheme, vocan defs, changes of behavior of them, *(adding a new required field to scheme**)
2. (spa) publicly adding changes (adding an optional field, adding a new type, etc)
3. (sb) privately breaking changes (everything is public in the spec, so probably no such changes in spec?)
4. (sa) privately adding changes (everything is public in the spec, so probably no such changes in spec?)
5. (sf) fixing public and private bugs (fixing types in spec, defs, etc.)

So now, let's talk about the SDK. Since SDK is "tied" to MMIF spec versions, there are two different sources of the breaking changes (pb in the SDK code itself, and spb from changes in the spec)

---

I don't think four-digit scheme (as proposed above by me) won't work, as long as we use x.y.a.b digits where

• x is tied to spb changes (BREAKING!)
• y is tied to spa changes
• a is tied to pb changes (BREAKING!)
• b is tied to other changes in the code because, sorting of version strings will mix and mess up the concept of breakages, and nuke the way we specify the dependency.

To that end, I'm now thinking among these three schemes

• x.a.b - only tied to major spec version
• x.a.y.b - four-digit scheme, but re-ordered to work with sorting
• a.b.c - no tie to the MMIF spec version at all
• a.b.c.x-y-z - MMIF spec version as the "build" number