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. _______________________________________________ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
