I confess I am not much of a versioning theorist, but the more I think about it, the more I come to the conclusion that SPARQL 1.1 should be called SPARQL 2.0.
To my knowledge, I understand that there is nothing in 1.0 that is unsupported/deprecated in 2.0, but the latter really is a world apart (FYI I didn't think that 1.1 had twice as many features as 1.0. so it should be called 2.0)
Much of the discussion happened here - http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0135.html - many of the working group participants thought that "SPARQL 2" would unconsciously imply a lack of backwards compatibility and could scare people away from it.
My suggestions at the time were:
I'm largely with you - I don't see how adding an update language, making a completely different beast of the thing, can logically just be a minor version update. This is a much more fundamental change then OWL 1 to 2.
Yes it should probably be called SPARQL 2.0, this is a classic example of feature creep IMO but I wouldn't complain too much as it gives us loads of cool features to play with which as database_animal says should have been there to start with.
Wrt Barry's point about update language there was already a non-standardised update language as a member submission so I think the original intention was that it would be tidied up a little and rubber stamped but they ended up making a lot more changes to it.
There is one actual breaking change in the query specification but it it so minor and obscure unless you're writing SPARQL parsers you won't even have known about it.
With SPARQL 1.0 you could write the following:
SELECT * WHERE { ?s ?p 1. }
And the plain literal would be taken to mean "1."^^xsd:decimal
Whereas in SPARQL 1.1 the same query means something different because it was decided that this could be confused with a query like SELECT * WHERE { ?s ?p 1 .} - note the space between the 1 and the .
Thus in SPARQL 1.1 the same query would actual take the plain literal to mean "1"^^xsd:integer which is probably what the author of such a query meant anyway.
Perhaps the people involved are modest. Certainly they could be better at marketing.
I really had no use for SPARQL 1.0, because I was already hooked on features from SQL, such as aggregates. Today, I prefer to write SPARQL 1.1 queries over SQL queries.