Bob Proulx wrote:
>>You seem to believe that RPMs and other package tools require versions of
>>the form x.y.z. Although I know nothing about RPMs, I know Debian finds
>>2.01 as a perfectly acceptable version number.
>>
>
> Yes a perfectly acceptable version number. But which version is the
> later, 2.01 or 2.1?
2.01<2.1, thefore 2.1 is greater.
>
>
>>If Redhat or whomever implemented the RPM system insists on versions of the
>>form x.y.z, (which is absurd, and almost certainly false) then they must be
>>changing the version number of thousands of programs anyway.
>>
>
> They do not. You can call the version number of an rpm or deb
> anything including "herman" if you want. But if you want it to
> upgrade smoothly then it needs to be something that the package tool
> can tell is newer or older. Otherwise you might find yourself
> installing a newer package that the tool thinks is an older and having
> it block you trying to prevent you from upgrading to an older version.
> Usually in that case you need special handling to clean up the mess.
>
RPMs look for a version something of the form "#.#[.#]" where (I
believe ... don't have the Max RPM book handy) the "." can be any
punctuation (".",",","-","_",etc.) and I believe as of RPM 3.0 I think
it also handles alpha sorting too (again, I don't have the book handy).
>
>>I vote for numbering such as 2.01. It works just great, why change it.
>>
>
> And if it doesn't work? :-)
It will work. It's fine for machines, but for us humans, there's 3
datapoints that it would be useful to track:
Major Release Number: Releases that significantly change the WAY SA works
and probably break things during the upgrade.
Minor Release Number: Additional features, changes that make installation
non-trivial.
Patch Level: Bug fixes and additional features that do not significantly
alter the functionality of existing SA configurations.
Since Perl drops any "_" characters it finds in a version number,
then using the form "2.0_1" is just as good as "2.01" and will work just
as well with RPM and I suspect DEB packaging systems. It also makes the
version number more human readable and easier to add patches quickly to
the "stabel" system while not forcing the "devel" system to mature too
quickly to get a fix/feature out-the-door when there's a need for it (eg
the quick release of 2.01).
Mat Sergeant said:
>Finally, if you do:
>
>$VERSION = '2.1_0';
>
>Then CPAN treats it as a beta, and won't install it - it'll do that
with >any
>version with an underscore in the distribution name (note that this
can >be
>different than the actual $VERSION - the underscore rule is just for the
>tar.gz file name). [:-)]
Hmmmm... then why did it not present problems with perk itself?
5.005_003 upgraded to 5.005_006 (or something like that) without any
problems for me when it was necessary to do so. Is that because the tar
files were something like "perl-5.005.003.tar.gz" or something?
Don
--
--------------------------------------------------------
Donald L. Greer, Jr [EMAIL PROTECTED]
System Administrator Voice: 512-300-0176
AustinTX http://www.AustinTX.COM/
All opinions are my own. Flame me directly.
"I don't necessarily believe software should be free...
but if you pay for it, it should work!" -- Me
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
