Schema models are version-aware, but CLI tool is not

[geezyx]

I could be totally confused here, but I was looking at implementing some new formatting output to commands/docs/gitbook, and the output would be dependent on component schema v3.1.0 (and possibly even a later version depending on how opencontrol/schemas#70 goes).

Doesn't this pose a problem for backwards compatibility? If the CLI tool is written expecting functions that are only available in later schema versions, then generating a gitbook for an older schema version would fail.

@jcscottiii @afeld, curious to hear your thoughts!

[jcscottiii]

For example here's the interface for a component: https://github.com/opencontrol/compliance-masonry/blob/master/lib/common/component.go

Version 2.0.0 has a function for looking at control origin but the actual schema does not have it. So we just put a empty value.
https://github.com/opencontrol/compliance-masonry/blob/master/lib/components/versions/2_0_0/component.go#L116

Version 3.1.0
https://github.com/opencontrol/compliance-masonry/blob/master/lib/components/versions/3_1_0/component.go#L126

It's up to the tool (in this case gitbook templater) to know what to do when it gets bad/empty input.

[jcscottiii]

We want to maintain a sliding window of supported schemas but besides dropping supporting schema versions out of future versions masonry, there's currently no way to enforce that.

Maybe create a file that contains metadata. Created with X.Y.Z version of masonry.
But anyway, it's not flushed out yet to give a guarantee