I agree that it would be good to have the same version number for the entire family of specs. 

Version numbers are a bit of a bike shed, and it's easy to lose enormous amounts of time discussing the optimal version number. To me, the two requirements are (1) the number should be the same for each spec in the family, and (2) the number needs to be >= 2.1.

If we want to avoid going directly from XQuery 1.0 to XQuery 3.0, we could do, say 2.5. Or we could go to 3.0, with a note in the status section explaining the jump.

My personal opinion only. The chairs decide this kind of thing, not me.

We have discussed bringing the version numbers of all the specs into alignment,
and there was a good level of agreement that was desirable, though it has
proved more difficult to get consensus on what the aligned version number
should be. It ought to be easy, but there are psychological factors in choosing
a version number, there are unstated but strongly-held beliefs about the
correlation between the size of the numeric increment and the level of
compatibility, there are process issues (like changing WG charters), and there
are technical issues in changing the build system. In an ideal world I agree
with you entirely that 3.0 would be a more logical choice than 2.1.

David, thanks for opening (yet another) discussion on this subject.  I've taken the liberty of re-characaterizing this Bugzilla entry against XPath 2.1, since it is (in some ways) the primary spec that links XSLT 1.0, XSLT 2.x, XQuery 1.x, and our other specs together.  I've also reassigned the bug to myself. 

Before I say anything else, I want to reassure you and everybody else who reads this bug that the issue is well-known in the XSL and XML Query WGs, that is has been discussed on several occasions, and that none of us really believe that the issue has been resolved.  But, as both Jonathan Robie and Mike Kay indicated in their comments, there are many factors to consider, not the least of which is the tradeoff in WG time spent debating version numbering versus fixing technical bugs and adding/refining new features. 

Sharon Adler (Chair of the XSL WG) and I (Chair of the XML Query WG) have just now spoken about this bug and several other events related to the same subject, and I agreed to write a comment for the bug.  Most of the content of this response reflects our shared opinion, so I'll indicate clearly where I say something that is my separate, personal opinion. 

I want to correct something that Jonathan said: The version numbers of W3C specs is not something that the Chairs of WGs decide.  Although the Chairs may have strongly-held views on the subject, we have used and will continue to use the consensus process to make such decisions.  A consensus among the relevant (XSL and XML Query) Working Groups' participants and the responsible W3C Team/Staff members is the appropriate mechanism, which Sharon and I are committed to use. 

I agree with the premise that having a common version number among the various closely-related specs is desirable.  I (personally) am not convinced that "3.0" is the best choice, but I wouldn't stand in the way of a consensus on that value.  Here are some values that have been discussed, along with (what I believe is a fairly reasonable) brief summary of the pros and cons of each:

* Leave the values as they are now -- Pros: the values are already known and in wide use in discussions, there are published documents using those values, and the entire infrastructure of development, editing, and maintenance is built around those values.  Cons: having different values for documents that are essentially bound together is confusing, especially to the vast majority of users who are not part of the development process. 

* Change all documents' version numbers to "2.1" -- Pros: the values for XQuery and the "supporting" documents (e.g., Data Model, Functions & Operators, Serialization) will align with XPath and XSLT, and the increment from "2.0" to "2.1" reasonably reflects the relatively small increase in functionality.  Cons: the level of functionality probably increased more than a ".1" version number suggests; end users may be confused about why XPath and XSLT version numbers aren't changes, while the other documents' version numbers were; significant work will be required in the development system where the documents are edited and generated. 

* Change all documents' version numbers to "3.0" -- Pros: changing all document numbers at once sends a clear signal that something significant happened, so consumers will take notice; the "major version number" change signals that there are significant changes/improvements in the specs.  Cons: "What happened to XQuery 2.0?" is the question we'll be answering for years to come; significant work will be required in the development system where the documents are edited and generated. 

* Change the entire scheme to use a date-based scheme -- Pros: this has been used by other standards (e.g., SQL:1999, SQL:2003, SQL:2008); it avoids having to decide whether the first version of a new spec in the collection (e.g., XQuery Scripting Extension) should be numbered "1.0" or (e.g.) "3.0".  Cons: the W3C has no history of date-based version numbering; it's not easy to predict the year when a complex set of specs will reach Recommendation; significant work will be required in the development system where the documents are edited and generated. 

As you can see from that limited summary above, the decision isn't easy to make, nor is the best answer immediately obvious.  In joint teleconferences of the XML Query WG and the XSL WG (with admittedly limited attendance by XSL WG participants), there was not an absolute consensus to make a version numbering change at all (and, to be honest, the Chairs are unenthusiastic about doing so), and there was absolutely no consensus on what to select if a change were to be made. 

However, there will be a Joint Face-to-Face Meeting of the two WGs in mid-July, and this subject will be on the agenda of that F2F meeting.  I cannot promise that we'll reach a consensus to make a change or to select a specific value for a change, but I assure you that we will try.

The WGs discussed this subject at great length, several times.  It was very difficult to reach a consensus, but we have achieved it.

XQuery, XPath, XSLT, XQueryX, Data Model, Functions and Operators, and Serialization will all be published as version 3.0.  The first Working Drafts displaying that version number are expected to be published before the end of the calendar year (2010).

good luck with the new drafts (and new numbers:-)

closing....