release numbers (was: [wplug] CMU installfest this Friday 7th Feb)

[Vanco, Donald]

Alexandros Papadopoulos wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 04 February 2003 10:43, Nick Iglehart wrote:
>> It has to be understood that any software's first release is going to
>> be buggy.  While Microsoft releases major versions and then slowly
>> updates them, Linux vendors tend to release major versions and then
>> release minor versions as updates.  Any .0 release is going to have
>> issues and that is why it is generally recommended to wait for .1's,
>> although I generally wait for .3's.
> 
> I don't see how this relates to a distribution release number.
> Incrementing the major number is a pure marketing decision and (at
> least in this case, RH7.3 -> RH8.0) doesn't have anything
> *really* that
> new, compared to the previous version.

	BZZZZT!  Wrong again.
	Red Hat release numbers for dummies:
	Minor number changes (e.g. 7.2 -> 7.3) = bugfixes, minor utility
updates, etc
	Major number changes (e.g. 7.3 -> 8.0) = dramatic change to the base
libraries - in this case going to glibc 3.x

	It's a plan.  It has reason. It has nothing whatsoever to do with
marketing.  If you want to see an example of "revision envy" take a look at
Mandrake.

	Please don't comment on that which you don't know.....

> There was a thread in the linux kernel mailing list a while ago, about
> whether the next major release of the kernel should be named
> 2.6 or 3.0
> - - it doesn't change the product, 
	
	BZZZZT!  Dig a little deeper on the kernel list, the logic is there
(whether or not you adhere to it is another issue)  Just as when the kernel
went from 1.0 to 2.0 then to 2.2 there are core changes reflected in the
increment.  "How core = increment ?" is the current debate......

> it only changes people's
> perceptions. In this case, interestingly enough, this perception has
> backfired on Red Hat (and any other distribution I guess), resulting
> in the urban legent that all .0 releases are buggy.

	BZZZT!  It's not urban legend - it's a know fact that RH .0 releases
are buggy - even RH will tell you.


> When was gcc 2.96 included in the distribution as an official
> compiler? That must've been the most buggy one :-)

	Yes, this was a really bad decision and the crack pipe must have
been glowing hot that day, but fixes were put into place quickly (new
gcc/glibc as well as the "application compatibility" package set) - and it
was, after all, a .0 release.


Don