W3C home > Mailing lists > Public > public-sparql-12@w3.org > April 2019

RE: Thoughts about backwards compatibility

From: Boris Pelakh <boris.pelakh@semanticarts.com>
Date: Wed, 24 Apr 2019 14:58:03 +0000
To: SPARQL 1.2 Community Group <public-sparql-12@w3.org>
Message-ID: <BN6PR1101MB22417C3E905640959205248BFB3C0@BN6PR1101MB2241.namprd11.prod.outlook.com>
Given that this is SPARQL 1.2, semantic versioning would require strict backward compatibility, since the major version is not changing. Nor have I seen any proposals that would require a compatibility-breaking change. 

In the cases where the previous standard behavior is undefined, or vendor dependent, or non-existent, the new standard can mandate anything without breaking compatibility. 

Boris Pelakh
Ontologist, Developer, Software Architect

-----Original Message-----
From: Jerven Tjalling Bolleman <Jerven.Bolleman@sib.swiss> 
Sent: Wednesday, April 24, 2019 6:15 AM
To: SPARQL 1.2 Community Group <public-sparql-12@w3.org>
Subject: Thoughts about backwards compatibility

Hi All,

I thought to quickly write about my thoughts regarding backwards compatibility.
These are just my thoughts and I am just providing them for discussion.

My feelings on the matter are that there are two kinds of backwards compatibility.
The first is "formally" not backwards compatible, i.e spec A says a certain kind of query should return a specific result and spec A+ defines a second different result, then it is not formally backwards compatible.

Second is the "marketplace" backwards compatible.
Same situation as above, but no one ever implemented A as specified or no-one ever send that kind of query.
Then while there is a formal change in behaviour no one is impacted because no one used the behaviour.

I am OK with breaking "formal" backwards compatibility but I am not at all keen on breaking "marketplace" backwards compatibility.
In that regards I see as an example to follow the Java language stewards whom have the same kind of problem.
There is a lot of code in the wild, doing even wilder stuff, making money and solving problems.
Breaking such code should only be done in extremis and after careful evaluation.

Being a very small community I think we can't afford splits like python2 to 3 or even worse Perl5 to 6.


Jerven Tjalling Bolleman
SIB | Swiss Institute of Bioinformatics
CMU - 1, rue Michel Servet - 1211 Geneva 4
t: +41 22 379 58 85 - f: +41 22 379 58 58 Jerven.Bolleman@sib.swiss - http://www.sib.swiss
Received on Wednesday, 24 April 2019 14:58:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 24 April 2019 14:58:34 UTC