|Summary:||Monolithic Second Release (6.8.0) must fix|
|Product:||xorg||Reporter:||Jim Gettys <jg>|
|Component:||* Other||Assignee:||Xorg Project Team <xorg-team>|
|Status:||RESOLVED FIXED||QA Contact:|
|Priority:||highest||CC:||ajax, billy.biggs, dberkholz, eta, keithp, kem, krh, pip, roland.mainz, stuart.kreitman|
|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|
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 220.127.116.11 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 18.104.22.168 > 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 22.214.171.124 Please apply this patch before tagging the tree as 126.96.36.199 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 188.8.131.52 Thanks! I will update the version for cygwin in the next release candidate and the final release.