- From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
- Date: Thu, 26 Mar 2009 10:08:53 +0000
- To: "Orri Erling" <erling@xs4all.nl>
- Cc: "'Ivan Herman'" <ivan@w3.org>, "'SPARQL Working Group'" <public-rdf-dawg@w3.org>
On 26 Mar 2009, at 09:56, Orri Erling wrote: > Hi > > This would be a matter of perception. > > The fact is, as a regular web developer would see it, that if the WG > ,manages to agree on update, aggregates, expressions, grouping and > nesting, > then it becomes, for the first time, possible to write what one > would call a > regular database driven application without relying on vendor specific > extensions. For me, yes. > On its own merits, this would warrant a major version number. But > if one > does give it a new major number, one offhand acknowledges that the > previous > spec was somehow insufficient. Hence it seems that the threshold for > issuing new major numbers is very high. Oy, this is exactly what one should avoid. Major/minor numbers get us into rathole discussions about whether this or that change passes the major threshold (as if that were independently determinable), worries about whether it signals "too much" change or "too little change" or whether its dissing the old spec. (See the furor about XML 1.0...5th edition) Here's my (made up) rule: If it's not errata, we bump the major the major version. If it is errata, then we publish errata :) I wish the W3C would adopt such a policy overall to prevent repeated rathole discussions. LET ME NOTE: I will not oppose any numbering scheme. I don't think date based ones will fly with the W3C as a whole. I think there are no substantive (such that we can determine independently of gut feels) arguments to be made about whether a change is major or minor. I think we're not going to do any serious market research to determine what sells best. Cheers, Bijan.
Received on Thursday, 26 March 2009 10:09:30 UTC