Am 05.02.2016 um 14:24 schrieb Markus Krötzsch:
I feel that this tries to evade the real issue by
making formal rules about what
kind of "breaking" you have to care about. It would be better to define
"breaking change" based on its consequences: if important services will stop
working, then you should make sure you announce it in time so this will not
happen. This requires you to talk to people on this list. I think the whole
proposal below is mainly trying to give you some justification to avoid
communication with your stakeholders. This is not the way to go.
It's a way to prevent unpleasant surprises, and avoid unnecessary work.
Talking about planned changes early on is certainly good, and we should get more
organized at this.
However, I would like to avoid having to treat *any* change like a breaking
change. Breaking changes should be communicated a lot earlier, and a lot more
carefully, then, say, additions and extensions.
I tried to write down what clients *shouldn't* rely on. As Tom pointed out,
these are really general design principles. They are not really specific to
Wikibase, except for the "data type vs. value type" thing. Any software
processing third party data should follow them.
how should a SPARQL Web service communicate problems
that occurred when
importing the data?
By informing whoever maintains the import, by writing to a log file or sending
mail. That's the person who can fix the problem. That's who should be informed.
Our tools rely on being able to use all data, and the
easiest way to ensure
that they will work is to announce technical changes to the JSON format well
in advance using this list. For changes that affect a particular subset of
widely used tools, it would also be possible to seek the feedback from the
main contributors of these tools at design/development time.
Any we do that for breaking changes. I did not expect additional data types to
cause any trouble. After all, you can still inject the data, since the value
type is know. For a long time, out dumps didn't even mention the data type at all.
I am sure everybody here is trying their best to keep
up with whatever
changes you implement, but it is not always possible for all of us to
sacrifice part of our weekend on short notice for making a new release before
next Wednesday.
To avoid this problem in the future, I tried to spell out what guaranties we
*don't* give, so a simple addition doesn't things don't break horribly.
That doesn't mean we don't plan to communicate such changes at all, or better
than we did now. We do. But this kind of thing is clearly distinct from actual
"breaking changes" in my mind.
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.