No - please. Point 8 from Semver with some personal markup: "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. ------------------------------------------------------------------------------------------ --------->> It MAY include minor and patch level changes. <<------------ ------------------------------------------------------------------------------------------ Patch and minor version MUST be reset to 0 when major version is incremented." You can make a major version release with just minor and patch level changes. The fact that there were an incredibly large amount of these meant that it should have been a major version People with old SPARQL 1.0 queries are going to look at the new specs because there are a significant amount of new features Right.... And guess what, you can tell them on the website that the great thing about SPARQL 2.0 is that there were no breaking changes from SPARQL 1.0 (maybe in green) "We're doing those people a disservice by sweeping the fact that 1.1 is back-compatible under the carpet" You're going to do yourselves a major disservice by telling people that SPARQL 1.1 doesn't have lots of great new features. Here is a link below: http://answers.semanticweb.com/questions/13671/sparql-11-why-isnt-it-20 Subject: Re: Wishlist for SPARQL 1.2: Compatible query-hints, extra math operators From: [email protected] Date: Thu, 1 Aug 2013 12:29:40 +0100 CC: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] To: [email protected]
I strongly disagree. For end users it's very significant if they have to re-write all their old SPARQL 1.0 queries or not, saying it "just told people that there were no breaking changes" is undervaluing the importance of that information IMHO. There are a group of people that follow this stuff closely, and there are a group of people that use these technologies regularly, but don't follow the "community" - mostly in industry. We're doing those people a disservice by sweeping the fact that 1.1 is back-compatible under the carpet. - Steve On 2013-08-01, at 12:16, william greenly <[email protected]> wrote:Semver is a good guideline and generally tells you the conditions under which you must increment minor a major versions. It does not stipulate at any point that you must not increase the Major version unless you introduce incompatible API changes. I know you guys discussed this with regards to SPARQL 1.1, but generally if there are a lot of majors changes then increase the major version number even if they are not breaking. You won't be wasting vendors time - they are still going to test their products and probably re-read the specs even if you tell them there are no breaking changes. Equally, adopters across the board won't disqualify something that has a great set of new features (look at HTML5) Calling it SPARQL 1.1 just told people that there were no breaking changes (but omitted to tell them anything else). Many Thanks, Will Subject: Re: Wishlist for SPARQL 1.2: Compatible query-hints, extra math operators From: [email protected] Date: Thu, 1 Aug 2013 09:57:08 +0100 CC: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] To: [email protected] Que? If it breaks back-compatibility then it should be SPARQL 2, if not 1.2. http://semver.org/ - Steve On 2013-07-30, at 15:15, william greenly <[email protected]> wrote:Excellent - Yes! SPARQL 1.2. If we want to follow in the footsteps of SPARQL 1.1 we should ensure 1.2 has lots of major changes in protest against semantic versioning. > Date: Tue, 30 Jul 2013 16:05:27 +0200 > From: [email protected] > To: [email protected]; [email protected]; > [email protected];[email protected] > Subject: Wishlist for SPARQL 1.2: Compatible query-hints, extra math operators > > Dear Workgroup, All, > > Maybe not the best moment to bring this up as the ink on SPARQL 1.1 is > not even dry yet. But looking to the future could we start thinking > about SPARQL 1.2 and what could be standardized there. > > The first need I am seeing is the need to standardize query hints. > > Oracle uses extra prefix declarations for query hints [1]. > BigData uses magic BGP's [2] > Virtuoso introduced a new keyword ASSUME [3] > > The BigData and Virtuoso approach introduce query incompatibilities > which is unfortunate. Oracle is ok in this respect as the unused > prefixes won't affect any strictly compatible sparql engine. I like the > idea that any SPARQL query will run on any store the only thing changing > is speed. Extra keywords or non existing BGP's break this utopia :( > > The second is an expansion of the basic math operators to include at > least (square)root. (square)root is very hard to implement using the > current SPARQL constructs yet is a very useful function. (even if not exact) > > Regards, > Jerven > > > > [1] > http://docs.oracle.com/cd/E18283_01/appdev.112/e11828/sem_jena.htm#CBBIAGAF > [2] http://sourceforge.net/apps/mediawiki/bigdata/index.php?title=QueryHints > [3] > http://sourceforge.net/mailarchive/forum.php?thread_name=51F67BB8.7030302%40openlinksw.com&forum_name=virtuoso-users > > > > > -- > ------------------------------------------------------------------- > Jerven Bolleman [email protected] > SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85 > CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58 > 1211 Geneve 4, > Switzerland www.isb-sib.ch - www.uniprot.org > Follow us at https://twitter.com/#!/uniprot > ------------------------------------------------------------------- >
