Bug 351 - Monolithic Second Release (6.8.0) must fix
Summary: Monolithic Second Release (6.8.0) must fix
Alias: None
Product: xorg
Classification: Unclassified
Component: * Other (show other bugs)
Version: unspecified
Hardware: All All
: highest blocker
Assignee: Xorg Project Team
QA Contact:
Depends on: 213 255 297 303 337 339 340 342 368 474 687 719 738 770 828 829 843 846 847 855 859 871 897 922 947 961 962 972 976 990 993 995 997 998 999 1007 1020 1024 1026 1029 1030 1031 1033 1041 1042 1044 1047 1050 1051 1053 1055 1057 1060 1062 1065 1070 1083 1084 1091 1101 1102 1103 1104 1105 1108 1119 1123 1124 1125 1127 1131 1132 1133 1134 1137 1138 1139 1147 1148 1149 1154 1156 1157 1160 1168 1179 1180 1182 1188 1203 1207 1210 1212 1213 1216 1221 1229 1231 1234 1238 1249 1271 1273
Blocks: 1690
  Show dependency treegraph
Reported: 2004-03-19 08:13 UTC by Jim Gettys
Modified: 2011-10-15 15:48 UTC (History)
10 users (show)

See Also:
i915 platform:
i915 features:

Patch to bring Cygwin Version number to (652 bytes, patch)
2004-09-01 10:55 UTC, Alexander Gottwald
no flags Details | Splinter Review

Description Jim Gettys 2004-03-19 08:13:44 UTC
This is a release blocker bug for the second monolithic release.
Comment 1 Mike A. Harris 2004-04-03 13:56:27 UTC
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.

Comment 2 Daniel Stone 2004-07-04 01:41:47 UTC
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'. 
Comment 3 Eric Anholt 2004-07-12 17:38:07 UTC
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.
Comment 4 Mike A. Harris 2004-07-12 21:54:34 UTC
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)
Comment 5 Kevin E. Martin 2004-08-06 13:24:13 UTC
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
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
Comment 6 Kevin E. Martin 2004-08-10 14:43:21 UTC
(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
> 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.
Comment 7 Mike A. Harris 2004-08-10 19:33:01 UTC
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.
Comment 8 Donnie Berkholz 2004-08-10 19:54:46 UTC
Similar goes for ebuilds: I'm hoping to do it tonight, but cvs over dialup on an
overheating-prone laptop isn't much fun.
Comment 9 Alexander Gottwald 2004-09-01 10:55:42 UTC
Created attachment 806 [details] [review]
Patch to bring Cygwin Version number to

Please apply this patch before tagging the tree as

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
Comment 10 Kevin E. Martin 2004-09-01 12:31:46 UTC
(In reply to comment #9)
> Please apply this patch before tagging the tree as

Thanks!  I will update the version for cygwin in the next release candidate and
the final release.
Comment 11 Kevin E. Martin 2004-10-21 19:20:03 UTC
The release has shipped.  Closing.
For the next X.Org Foundation release, see bug 1690.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.