From: "Donald Greer" <[EMAIL PROTECTED]>
> Matt 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
> >diffe
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
>
- Original Message -
From: "Bob Proulx" <[EMAIL PROTECTED]>
> > 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 ac
I think the normal way to deal with this is for RPM users to just give the RPM a version number that's something sensible derived from the package version number.
C
On Mon, 2002-01-28 at 20:33, Bob Proulx wrote:
> Fine, until you throw that at CPAN.pm, which checks $SomeModule::VERSI
> 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?
> If Re
On Mon, Jan 28, 2002 at 09:51:37PM -0700, Bob Proulx wrote:
> > wide scheme of things, because in Perl we have CPAN, and CPAN treats
> > $VERSION as a floating point number, and does comparisons that way, and
>
> I think it would be a fine compromise to consider perl versions as
> perl versions i
> wide scheme of things, because in Perl we have CPAN, and CPAN treats
> $VERSION as a floating point number, and does comparisons that way, and
I think it would be a fine compromise to consider perl versions as
perl versions internal to CPAN and the program version for other usage
as the externa
> Fine, until you throw that at CPAN.pm, which checks $SomeModule::VERSION <
> $RemoteCPANSomeModule::VERSION before trying to install something.
>
> Think very carefully about breaking CPAN installation before going off on a
> rant about this.
I will return your statement to you. Think very ca
From: "dman" <[EMAIL PROTECTED]>
> On Mon, Jan 28, 2002 at 02:24:17PM -, Matt Sergeant wrote:
> | I've been saying all along - in perl $VERSION is a
> | number. So it does numeric comparison, just like I described.
>
> Sorry, I have trouble remembering which operator in perl is numeric
> and
On Mon, Jan 28, 2002 at 02:24:17PM -, Matt Sergeant wrote:
| > | > Gosh, 2.2 _is_ significantly older than 2.14. Who would have guessed?
| > |
| > | Fine, until you throw that at CPAN.pm, which checks $SomeModule::VERSION
| <
| > | $RemoteCPANSomeModule::VERSION before trying to install somet
> | > Gosh, 2.2 _is_ significantly older than 2.14. Who would have guessed?
> |
> | Fine, until you throw that at CPAN.pm, which checks $SomeModule::VERSION
<
> | $RemoteCPANSomeModule::VERSION before trying to install something.
> |
> | Think very carefully about breaking CPAN installation befor
On Mon, Jan 28, 2002 at 09:48:25AM -, Matt Sergeant wrote:
| From: "Bob Proulx" <[EMAIL PROTECTED]>
|
|
| > > | > I'd suggest a two digit minor version number, for example 2.01.2023
| > > | > rather than 2.1.2023, because then we don't have the stupidity of
| > > | > version 2.2.2023 being o
From: "Bob Proulx" <[EMAIL PROTECTED]>
> > | > I'd suggest a two digit minor version number, for example 2.01.2023
> > | > rather than 2.1.2023, because then we don't have the stupidity of
> > | > version 2.2.2023 being older than 2.14.4096 (like Apache does it:).
> > |
> > | Um, 2.2.* is older
- Original Message -
From: "Bob Proulx" <[EMAIL PROTECTED]>
> > No, this is Perl. Version numbers are floating point numbers. (yes I
know
> > it's a crap situation, but that's just how it works).
>
> Then how do you explain 5.005_03?
Underscore is a no-op in numbers in Perl. Try it:
> Depends on what the letter is used for. Vim 6 went from 6.0a to 6.0ax
> with 6.0b .. 6.0z 6.0aa ... in between. Those, however, were alpha
> and beta release with the final release simply "6.0". I think that is
> appropriate usage.
Actually, Vim is a good example of a bad example. Which of
On Fri, 25 Jan 2002, Bob Proulx wrote:
> Charlie Watts wrote:
> > Use letters for the second part.
> > 2.a.7.
> > 2.b.12
> > Just to be different. Everybody already uses numbers ... so mundane.
>
> And so standard and usable by a large audience of people and
> programs. If you want people to use
On Fri, Jan 25, 2002 at 08:24:28PM -0700, Bob Proulx wrote:
| > Note: letters will break this too.
|
| Letters are a pain because there are so few of them. When you run
| past z you either go to aa or decide that perhaps .27 is not such a
| bad idea after all.
Depends on what the letter is us
When I posted my previous comment about versions numbers I had not yet
noticed the discussion about it here. But version numbers are a pet
peeve of mine so watch out!
I can't suggest strongly enough that whole numbers separated by dots
is the cleanest solution available. Version numbers are not
> Use letters for the second part.
> 2.a.7.
> 2.b.12
> Just to be different. Everybody already uses numbers ... so mundane.
And so standard and usable by a large audience of people and
programs. If you want people to use the programs then things should
not be difficult just to be different.
Jus
> No, this is Perl. Version numbers are floating point numbers. (yes I know
> it's a crap situation, but that's just how it works).
Then how do you explain 5.005_03? Or 5.6.1? What kind of floating
point numbers are those? Even perl gave up on the leading zeros of
5.005_03 style of version num
Thomas Hurst wrote:
> I think maybe we should seperate the rules and the software. People
> who don't want to sit on the bleeding edge of the Perl may still like to
> stick to up to date rulesets, and it opens the road up for external apps
> to use it more easily.
Trouble is the rules which ge
Matt Sergeant wrote:
[...]
>>Um, 2.2.* is older than 2.14.*
>>
>>It's MAJOR.MINOR., not a decimal number. 2 is less than 14,
>>hence it's older.
>>
>
> No, this is Perl. Version numbers are floating point numbers. (yes I know
> it's a crap situation, but that's just how it works).
>
> Note:
> -Original Message-
> From: Greg Ward [mailto:[EMAIL PROTECTED]]
>
> On 24 January 2002, Matt Sergeant said:
> > No, this is Perl. Version numbers are floating point
> numbers. (yes I know
> > it's a crap situation, but that's just how it works).
>
> I think that rule was broken when t
On 24 January 2002, Matt Sergeant said:
> No, this is Perl. Version numbers are floating point numbers. (yes I know
> it's a crap situation, but that's just how it works).
I think that rule was broken when the next version after Perl 5.005
became Perl 5.6. Didn't they even introduce a new type e
* Matt Sergeant ([EMAIL PROTECTED]) wrote:
> - Original Message - From: "Thomas Hurst"
> <[EMAIL PROTECTED]>
> > Um, 2.2.* is older than 2.14.*
> >
> > It's MAJOR.MINOR., not a decimal number. 2 is less than
> > 14, hence it's older.
>
> No, this is Perl. Version numbers are floating poi
- Original Message -
From: "Thomas Hurst" <[EMAIL PROTECTED]>
> * Ged Haywood ([EMAIL PROTECTED]) wrote:
>
> > I'd suggest a two digit minor version number, for example 2.01.2023
> > rather than 2.1.2023, because then we don't have the stupidity of
> > version 2.2.2023 being older than 2.1
Hi all,
On Wed, 23 Jan 2002, dman wrote:
> On Thu, Jan 24, 2002 at 12:02:41AM +, Thomas Hurst wrote:
> | * Ged Haywood ([EMAIL PROTECTED]) wrote:
>
> | > I'd suggest a two digit minor version number, for example 2.01.2023
> | > rather than 2.1.2023, because then we don't have the stupidity
On Thu, Jan 24, 2002 at 12:02:41AM +, Thomas Hurst wrote:
| * Ged Haywood ([EMAIL PROTECTED]) wrote:
| > I'd suggest a two digit minor version number, for example 2.01.2023
| > rather than 2.1.2023, because then we don't have the stupidity of
| > version 2.2.2023 being older than 2.14.4096 (
* Ged Haywood ([EMAIL PROTECTED]) wrote:
> Hi there,
>
> On Wed, 23 Jan 2002, Donald Greer wrote:
>
> >So, perhaps the release posted this morning would be "2.0.0"?
> > and the devel release "2.1.0"? (or maybe "2.1.2023 -- 2.1.[4-digit
Ugh, please no Microsoftish version numbers. One
Use letters for the second part.
2.a.7.
2.b.12
Just to be different. Everybody already uses numbers ... so mundane.
On 23 Jan 2002, Craig Hughes wrote:
> Heh, one of my personal pet peeves is that people don't use string
> libraries where xxx123xxx sorts ahead of xxx20xxx -- I can't really
>
Heh, one of my personal pet peeves is that people don't use string libraries where xxx123xxx sorts ahead of xxx20xxx -- I can't really think of any situation ever where you would want sorting to happen the other way. Ever. I remember back in the early 90s a guy I knew at Stanford wrote an ext
On Wed, Jan 23, 2002 at 08:43:47PM +, Ged Haywood wrote:
| Hi there,
|
| On Wed, 23 Jan 2002, Donald Greer wrote:
|
| >Might I suggest a 2-prong numbering system (similar to Linux Kernel)
| [snip]
| >So, perhaps the release posted this morning would be "2.0.0"? and the
| > devel re
32 matches
Mail list logo
