Bug 351

Summary: Monolithic Second Release (6.8.0) must fix
Product: xorg Reporter: Jim Gettys <jg>
Component: * OtherAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact:
Severity: blocker    
Priority: highest CC: ajax, billy.biggs, dberkholz, eta, keithp, kem, krh, pip, roland.mainz, stuart.kreitman
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug 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    
Bug Blocks: 1690    
Attachments:
Description Flags
Patch to bring Cygwin Version number to 6.8.0.0 none

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.

;oP
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 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.
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 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.
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 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.
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 6.8.0.0

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.