W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: Versioning (again, sorry!)

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Wed, 07 Oct 2009 20:20:42 -0400
Message-ID: <4ACD305A.2080305@thefigtrees.net>
To: Paul Gearon <gearon@ieee.org>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
Paul Gearon wrote:
> On Wed, Oct 7, 2009 at 8:22 AM, Steve Harris <steve.harris@garlik.com> wrote:
>  Hi All,
>> I know we already discussed the versioning of the recs., and it was quite
>> contentious :) but I mentioned it in the office the other day and I got
>> complaints that the /Update and /Query rec's versions will be out of sync.
>> It was felt that having to say something like "this app requires backends
>> supporting protocol 1.1, query 1.1, and update 1.0" was too confusing to
>> people unfamiliar with SPARQL's history.
>> Anyway, just thought I'd mention it.
> It's worth mentioning.
> I completely agree. Even if we have to come up with a
> naming/versioning system that doesn't mesh completely with history
> (eg. skipping a version number), it would be far preferable to having
> multiple version numbers associated with a single SPARQL revision. The
> confusion that it's generating already shows that we need to rethink
> this.

Could you explain the confusion some more? I was a proponent of naming 
everything "2" in the first place, but I don't really see the complexity 
in Steve's example above. It seems reasonable to give a list of 
different versions that a particular application needs. Even if all the 
components of this round of standardization had the same number, it 
seems it would still be likely to have applications that need different 
versions. I don't think that the "standardization round" should really 
have too much impact on how people think about the individual 
components, but I'd like to understand where the potential confusion is.

Received on Thursday, 8 October 2009 00:21:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:58 UTC