-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
revise compatibility requirements #113
Comments
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 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
We could start our versionning on
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.
The text was updated successfully, but these errors were encountered: