RE: [cfengine] red hat 9 != 9.0

[Greg Haygood]

RedHat wants to simultaneously keep up with the rapid technology releases of
the other linux distributions while providing the stable/reliable releases
that most enterprise customers are looking for.  So they're going to provide
two distros:  "normal" RH Linux will provide all the cool bells-n-whistles,
but keep a short life cycle (4-6 months); and 'RH Enterprise Linux' will
give the enterprises something to rely on, and vendors something they can
certify against, with a lifecycle 

Official page: http://www.redhat.com/software/whichlinux.html
Explanation from a RedHat manager:
https://listman.redhat.com/pipermail/phoebe-list/2003-March/004919.html

So the normal Linux version numbering will drop any attempt at .X releases.
Either the updates come from RedHat Network, or they come in the next major
number release.

-g

-----Original Message-----
From: help-cfengine-bounces+ghaygood=brightlane.com@gnu.org
[mailto:help-cfengine-bounces+ghaygood=brightlane.com@gnu.org] On Behalf Of
Andrew Stribblehill
Sent: Tuesday, April 08, 2003 7:53 PM
To: help-cfengine@gnu.org
Subject: Re: [cfengine] red hat 9 != 9.0


Quoting Paul Heinlein <heinlein@cse.ogi.edu> (2003-04-08 05:56:59 BST):
> On Red Hat 9 systems, /etc/redhat-release reads
> 
>   Red Hat Linux release 9 (Shrike)
> 
> src/misc.c won't parse this correctly because it scans for "%d.%d". I 
> guess there are two ways to set the classes:
> 
> * just let it be redhat_9
> * by fiat, declare it both redhat_9 and redhat_9_0
> 
> The patch below, made against 2.0.6, takes the first approach, though
> I certainly can understand the arguments for the second. (Warning: I'm
> not a C hacker. This looks right to me, and it seems to work as
> expected on Linux/gcc boxes, but any fixes are certainly welcome.)

I hear that there's precedent for RedHat's marketing department to
drop the .0 -- apparently Redhat 7.0 was only retro-actively labelled
that. On this assumption, I think we should declare an implicit .0
for RH 9.

RedHat have always had genuine reasons for bumping the major version
number and I expect that if their next release doesn't have
compatibility problems with Shrike, they'll number it 9.1.

<plug type="shameless">If you want an example of code which groks 0,
1 or 2 numbers in a release name, look at the Debian release
parsing.</plug>

-- 
MALIN HEBRIDES
SOUTH OR SOUTHEAST 3 OR 4, OCCASIONALLY 5 IN WEST. MAINLY FAIR.
MODERATE OR GOOD


_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://mail.gnu.org/mailman/listinfo/help-cfengine