Having the version be refered to as "1" for X11R6.7 is confusing IMHO.
Calling the next release "1.1" seems like an equally bad idea to me.

I think a better approach in the future, is to give the in-development
releases that do not have a known version number yet, to be given release
codenames.  This practice is pretty standard at most software corporations,
and also in most large and medium sized OSS software projects.

For the version reported by the X server, it should probably follow a scheme
similar to XFree86, or the kernel or something, so that all development
snapshots don't show up as "version 6.7" in bug reports.  They show up
instead as "Version: 6.7.99.n" where n is some agreed upon numbering scheme.
XFree86 uses a monotonically increasing integer which is incremented every
2 weeks and a CVS snapshot dump is made (which may or may not even compile,
but usually does).  Once code freeze is entered and release candidates are
being made, the 4th level version is bumped to 900, then monotonically
incremented until the final release is made.

That scheme isn't the prettiest, but it is functional at least.  Another
scheme we could go with is one like the Linux kernel follows, where all
stable releases have an even numbered 2nd level version (2.0, 2.2, 2.4) and
all developmental releases have odd numbered 2nd level version (2.1, 2.3, 2.5).

Either way, some sane version numbering is needed, or we're going to be very
confused in bug reports and other aspects of development, and Xorg X11
users will also be very confused.  Having the CVS branch named after the
real release development version or name makes more sense than a number
pulled out of thin air.  If it is uniformly decided to use a random and
meaningless number though, I suggest that 1.1 is very boring, and that
we use 53.3245616 instead.  It holds the same amount of meaning, but is
more interesting, and will make people more curious about what it stands
for, and generally more interested in X.org due to the mystique of the
version numbering.

;oP

We discussed this on RW a while back (well, semi-RW: yourself, Jim, Keith, and 
myself, IIRC), and agreed that the first release should be codenamed 'Prawns, 
not shrimp'. I think we should use this for the second release, optionally 
contracted to 'prawns'. 

I definitely agree with the concerns about the monolithic release being numbered
from 1.0.  Everyone considers the last one to be 6.7.0, and we're putting in
some major new features, so I've renamed this bug to call the second release
6.8.0 unless we have some opposition to that.

Agreed, I've been calling it "X.OrgNG" for "next generation" and confusing
the hell out of people, simply because I wasn't aware of any discussion
that determined what the next version would be.  ;o)  It could easily have
been 6.7.1 or 6.8.0 or even 7.0 from some discussions that have occured in
months past.  6.8.0 seems the most sensible to me however, as it will contain
various new functionality and features such as XFIXES/DAMAGE/COMPOSITE, which
warrants a minor version bump from 7 to 8, but isn't large enough of a major
technological shift to warrant a shift from 6.7 to 7.0.  If ever there's a 6.7.1
released, which I hope there will for longterm maintenance support, it would
ultimately be 6.7.0 plus well tested and known safe bug fixes, and possibly
other minor changes backported from CVS as deemed safe via concensus somehow.

So 6.8.0 makes the most sense.  1.1 is confusing and meaningless, double or
triple so if we'd have to explain it to the general public.  ;o)

At this point we are just waiting on confirmation that the BOD approves the
X11R6.8 name.  When/if it does, I plan to change the XORG_VERSION_* to 6.7.99.1
and tag the tree with XORG-6_7_99_1 for the first snapshot release for people to
build packages for testing.  This matches the common practice for snapshot test
builds.

(In reply to comment #5)
> At this point we are just waiting on confirmation that the BOD approves the
> X11R6.8 name.  When/if it does, I plan to change the XORG_VERSION_* to 6.7.99.1
> and tag the tree with XORG-6_7_99_1 for the first snapshot release for people to
> build packages for testing.  This matches the common practice for snapshot test
> builds.

The BOD met this morning and approved the X11R6.8 name, and I have tagged the
tree as mentioned above (XORG-6_7_99_1).  Those doing test packaging, you can
now go ahead and grab this snapshot tag for your next test package.

For the curious out there wondering when RPMs will be available of this,
they are currently building, and will be publically available within a
short timeframe.  I'll make some announcements publically to gather testers
once things are ready.

Similar goes for ebuilds: I'm hoping to do it tonight, but cvs over dialup on an
overheating-prone laptop isn't much fun.

Created attachment 806 [details] [review]
Patch to bring Cygwin Version number to 6.8.0.0

Please apply this patch before tagging the tree as 6.8.0.0

Cygwin/X uses the same versioning scheme but can not include xorg.cf since the
ddx is far too different.

After the release I'll provide a patch to keep the version number in a separate
file.

(In reply to comment #9)
> Please apply this patch before tagging the tree as 6.8.0.0

Thanks!  I will update the version for cygwin in the next release candidate and
the final release.

The release has shipped.  Closing.
For the next X.Org Foundation release, see bug 1690.