Open crotwell opened 2 years ago
I see your concern and agree with it. It looks like a more general issue probably expected in other code development as well. Once there is any schema change applied, there needs to be a clear statement, what schema can validate which document (whatever we call it). To me, it is not that important what happens, but more important is to have a clear message about it directly in the schema, as you @crotwell suggest.
@chad-iris in #112 pointed to https://snowplowanalytics.com/blog/2014/05/13/introducing-schemaver-for-semantic-versioning-of-schemas/#schemaver
which might be useful for how to make the documentation more clear.
From this interesting post pointed by @chad-iris , we could derive some rule in order to clarify the schema evolution/incompatibilities:
The schema format is M-R-A
. 3 digits strictly > 0.
M
and R
, and inferior A)M
and inferior R
)We could start our versionning on 2-0-0
Some examples here:
A
A
R
R
M
Some ideas I like here :
Seems like this will require schema change due to schemaVersion being 'decimal'
Yes, the schemaVersion type must be changed for the next major version.
See: http://www.fdsn.org/xml/station/
It is not clear to me if this is sufficient for what is actually needed for "backwards compatibility". Validation across versions may be less important than if software written to use a 1.x version can be expected to parse a 1.y document without breaking. If that is important, then removing elements is ok, but adding them is not. This is opposite of the statement that
and so perhaps should be
I am not sure I am clear on how best to handle this, but I feel like schema backwards compatibility and document backwards compatibility kind of point in opposite directions.
Whatever is decided, should add a section to documentation overview.rst stating this, so it lives with the schema and not just only on the fdsn web site.