Mailing List Archive

One does wonder why patch releases are alphabetic. With 999 (that's
"ten thousand" to you and me) release levels available, why do we need
5.001[a-z]? Also, if they weren't alphabetic, then we could "require" them
like any major-minor-release.

-Eric

> From: Jared Rhine <jared@organic.com>
>
> [Citation date: Wed, 6 Dec 1995 16:52:22 +0000]
> TB == Tim Bunce <Tim.Bunce@ig.co.uk>
>
> TB> 1.0.4 is not a 'standard' module version number. See the Module List
> TB> and Exporter.pm.
>
> Sorry to start out inflamatory, but why did Perl use such a bogus standard
> for version numbers? All the world thinks that 3 or 4 level version numbers
> (like 1.0.4) are perfectly reasonable and understandable, and as a result,
> are heavily used in practice.

Well, RCS uses a.b.c.d, Oracle quite likes a.b.c.d.e.f.

Doesn't mean we all have to.

None of those are floating point numbers. They don't sort numerically or
lexically.

> The problem is in the 99-rollover; given two
> version numbers like 3.78 and 3.152, which is the more recent? I don't
> believe I should have to roll over to 4.00 once I reach 3.99 simply because
> the perl versioning standard wasn't far-thinking enough.

The 'perl way' (:-) allows you to use 3.0000078 if you feel you'll be
making that many minor releases.

Note that the module list says 'at least two digits'.

> IHMO, the excuse of numerical comparison is a poor one. One of my favorite
> quotes reflecting my development philosophy (courtesy of Larry) is "Given a
> choice between making things easy for the computer or easy for the user, the
> computer usually loses"; this forced two-level versioning standard certainly
> sacrifices ease-of-use and understandability for the sake of an "easier to
> implement" comparison.

Larry, like the Bible, is a rich source of 'handy' quotes for any occasion.

Note that Larry sets $] to "5.002" and not "5.0.2".

> Granted, I haven't actually run into the "greater
> than 99" version problem in any of my current perl development, but I'd be
> willing to bet than many developers here have worked on large,
> multi-developer projects where it is almost a necessity to have sub-versions
> greater than 99, even neglecting 3-level numbers.

There is a handy quote somewhere (anoyingly I forget the source) to the
effect that any piece of software that's been changed more than a few times
should be rewritten.

Anyway, anyone getting to, say, 1.73 can simply release the next version
as 1.731 then 1.732. Simple.

> [...] Neglecting that, would I be chastised according to the "standard"
> were I to implement a greater-than-99 and 3-level-aware require_version for
> my own development?

You're welcome to do whatever takes your fancy for your own development!

:-)

> BTW, I would claim that the current standard is not adequately documented.

That's true.

Care to offer a patch?

Tim.

> TB> 1.0.4 is not a 'standard' module version number. See the Module List
> TB> and Exporter.pm.

>Sorry to start out inflamatory, but why did Perl use such a bogus standard
>for version numbers?

Just cope.

--tom

[Citation date: Wed, 6 Dec 1995 21:44:25 +0000]
TB == Tim Bunce <Tim.Bunce@ig.co.uk>

JR> All the world thinks that 3 or 4 level version numbers (like 1.0.4)
JR> are perfectly reasonable and understandable, and as a result, are
JR> heavily used in practice.

TB> Well, RCS uses a.b.c.d, Oracle quite likes a.b.c.d.e.f.
TB>
TB> Doesn't mean we all have to.

Of course not, but I believe that if heirarchical version numbers are so
well-established and commonly-understood, the Perl community should only
deviate for good, explicitly-described reasons. To deviate arbitrarily just
violates the principle of least surprise. In this case, I believe it also
violates a principle of greatest functionality for no particularly good
reason.

Please note, I'm not saying that there aren't good, solid, well-thought-out
reasons for doing what we did. It's just that, since I'm in the other camp,
I don't fully understand the reasoning. Summarizing Tim's message, am I
correct that the two primary reasons are:

+ The versions can be compared numerically.
+ You can use more decimal places if you really need to.

I can see that, although I would counter the first with the claim that since
the comparison is only need in two places, it wouldn't be that hard to do a
implement a more sophisticated comparison.

TB> None of those are floating point numbers. They don't sort numerically
TB> or lexically.

I'll grant that, but it's not like those are the only valid ways of
comparing identifiers; I can define the syntax and semantics however I want,
and provide my own comparison function. We do it all the time.

TB> Note that the module list says 'at least two digits'.

Hmm, the version I checked (2.13) says "It's a good idea to use two digits
after the decimal point", not "at least two digits". Ah, saved by being
correct again, Tim :) My mirror of the modules list is out of date. The
language of current version is more to my liking.

TB> Note that Larry sets $] to "5.002" and not "5.0.2".

Chuckle; I won't mention that the current version is actually 5.002beta1d :)
There are also significant problems with this scheme, since it's well known
that the 'require x.xxx' has been pretty useless as of late, since 'require
5.001' was a far cry from what was actually desired: 'require 5.001m'.

TB> There is a handy quote somewhere (anoyingly I forget the source) to
TB> the effect that any piece of software that's been changed more than a
TB> few times should be rewritten.

A nice, tidy sentiment, but it does tend to ignore the realities of software
development, especially multi-developer development.

TB> Anyway, anyone getting to, say, 1.73 can simply release the next version
TB> as 1.731 then 1.732. Simple.

Good point. Of course, I can't change from 2.87 to 2.088.

JR> BTW, I would claim that the current standard is not adequately documented.

TB> That's true.
TB>
TB> Care to offer a patch?

Sure. At this point, I think the only language that really needs to be
added is:

+ Version numbers are compared numerically. Non-floating point numbers
will give unpredictable results.
+ Packages expecting lots of revisions should probably start with three or
more decimal places.

Is that it?

BTW, it occurs to me that I should have tried to see if there were
discussions of the version-number standard in the archives before spouting
off. Is there any such discussion?

--
jared@organic.com / Organic Online / <URL:http://www.organic.com/Staff/jared/>

"To hear many religious people talk, one would think God created the
torso, head, legs and arms, but the devil slapped on the genitals."
-- Don Schrader

> From: Tom Christiansen <tchrist@mox.perl.com>
>
> > TB> 1.0.4 is not a 'standard' module version number. See the Module List
> > TB> and Exporter.pm.
>
> >Sorry to start out inflamatory, but why did Perl use such a bogus standard
> >for version numbers?
>
> Just cope.

:-)

Yeah, that's what I meant to say, but I got carried away!

> --tom
>

Tim.

p.s. Tom, any chance you could update the bug list web pages?

> From: Eric Arnold <Eric.Arnold@corp.sun.com>
>
> One does wonder why patch releases are alphabetic. With 999 (that's
> "ten thousand" to you and me) release levels available, why do we need
> 5.001[a-z]? Also, if they weren't alphabetic, then we could "require" them
> like any major-minor-release.

The patches have always been 'officially unofficial'.

Tim.

> From: Jared Rhine <jared@organic.com>
>
> TB> Note that the module list says 'at least two digits'.
>
> Hmm, the version I checked (2.13) says "It's a good idea to use two digits
> after the decimal point", not "at least two digits". Ah, saved by being
> correct again, Tim :) My mirror of the modules list is out of date. The
> language of current version is more to my liking.

My version now says:

2.9 Give the module a version/issue/release number.

To be fully compatible with the Exporter and MakeMaker modules you
should store your module's version number in a non-my package
variable called $VERSION and use at least two decimal places
(e.g, $VERSION = "0.01"). Don't use a "1.3.2" style version.
See Exporter.pm in Perl5.001m or later for details.

It may be handy to add a function or method to retrieve the number.
Use the number in announcements and archive file names when
releasing the module (ModuleName-1.02.tar.Z).
See perldoc ExtUtils::MakeMaker.pm for details.

> TB> Care to offer a patch?
>
> Sure. At this point, I think the only language that really needs to be
> added is:
>
> + Version numbers are compared numerically. Non-floating point numbers
> will give unpredictable results.

Er, that sounds like integers will give unpredictable results.
I'd say "invalid numbers such as "1.3.2" will give unpredictable results'.

> + Packages expecting lots of revisions should probably start with three or
> more decimal places.

I'd simply say 'sufficient decimal places'.

> Is that it?

I think it's important to explicitly give the one example that most
people will register and remember:

1.0 -> ... -> 1.9 -> 1.10 = Ooops!

> BTW, it occurs to me that I should have tried to see if there were
> discussions of the version-number standard in the archives before spouting
> off. Is there any such discussion?

Yes. Quite a long one :-) about the time I did the Exporter patch.

Tim.

>p.s. Tom, any chance you could update the bug list web pages?

well, yes, i did that late saturday or so.

--tom

> From: Tom Christiansen <tchrist@mox.perl.com>
>
> >p.s. Tom, any chance you could update the bug list web pages?
>
> well, yes, i did that late saturday or so.

It currently says

... current bug status for perl as of Wed Nov 15 20:01:41 MST 1995.

with 6 open critical bugs.

Tim.

>[Citation date: Wed, 6 Dec 1995 16:52:22 +0000]
>TB == Tim Bunce <Tim.Bunce@ig.co.uk>
> TB> 1.0.4 is not a 'standard' module version number. See the Module List
> TB> and Exporter.pm.
>Sorry to start out inflamatory, but why did Perl use such a bogus standard
>for version numbers?

Except for preferring the word "unfortunate" to "bogus" I'd like to
agree here. Both for numbering my own extension and in selecting
software to port it to the version number standard manages to be quite a
nuisance. The sites from which I take my perl versions seem to be
confused by it, often preferring unstable versions of Perl with nicer
numbers to stable versions with wierd number-letter combinations and the
"unofficial" stamp.

If the Perl standard of version numbers works, why don't Perl releases
follow that standard? It seems we are getting the worst of both worlds.

If the key word here is "cope", let those who designate Perl releases
set us skeptics the example. It won't be the first or last time they've
surprised me by teaching me new tricks. And if setting the example proves
too difficult, perhaps the point is then made.

Cheers!

Jeffrey Kegler, Algorists, Inc.
jeffrey@algorists.com, http://www.best.com/~jeffrey
743 East El Camino Real #338, Sunnyvale CA 94087

the notable version had the right dat.e

it's kinda hard to keep up on all this.

--tom

On Wed, 06 Dec 1995 14:25:13 PST, Eric Arnold wrote:
>
>One does wonder why patch releases are alphabetic. With 999 (that's
>"ten thousand" to you and me) release levels available, why do we need
>5.001[a-z]? Also, if they weren't alphabetic, then we could "require" them
>like any major-minor-release.
>

I don't think anybody here really _likes_ the alphabetic suffixes.

Hopefully, with faster patch cycles around the bend, we won't have
to put up with their ugliness. God knows we've all wanted to
write

require 5.001m;

at some point, but couldn't.

I can appreciate that Larry is the official maintainer of Perl,
but it would be a relief if Andy's patches can get real
numeric increments after sufficient testing by the porters.

- Sarathy.
gsar@engin.umich.edu

The answer, "all patches are officially unofficial" doesn't really hold
water, since nobody ever used the 5.001 release for more than a
milli-instant.

5.001m, for example (I think), was a requirement for a particular
version of PerlTk, and some other packages, but there was no way to use
"require" to force it. The various patch releases are/were the only de
facto releases for months at a time.

One of two things should happen: 1) don't publish the patches until
they can be consolidated into a tested mini-release, 2) continue
publishing the alphabetic patches, but create much more frequent
official releases that incorporate them. It doesn't make any sense to
have the only usable releases "unofficial".

-Eric


> From: Gurusamy Sarathy <gsar@engin.umich.edu>
>
> On Wed, 06 Dec 1995 14:25:13 PST, Eric Arnold wrote:
> >
> >One does wonder why patch releases are alphabetic. With 999 (that's
> >"ten thousand" to you and me) release levels available, why do we need
> >5.001[a-z]? Also, if they weren't alphabetic, then we could "require" them
> >like any major-minor-release.
> >
>
> I don't think anybody here really _likes_ the alphabetic suffixes.
>
> Hopefully, with faster patch cycles around the bend, we won't have
> to put up with their ugliness. God knows we've all wanted to
> write
>
> require 5.001m;
>
> at some point, but couldn't.
>
> I can appreciate that Larry is the official maintainer of Perl,
> but it would be a relief if Andy's patches can get real
> numeric increments after sufficient testing by the porters.
>
> - Sarathy.
> gsar@engin.umich.edu
>

Would I be looked on with contempt if I made some comment about someone
from Sun discussing patch issues? ;-) Especially if you start talking
about hardware revisions....

Strange sunspot activity caused Eric.Arnold@Corp.Sun.COM (Eric Arnold) to write
:
| The answer, "all patches are officially unofficial" doesn't really hold
| water, since nobody ever used the 5.001 release for more than a
| milli-instant.

5.001 wasn't supposed to exist for more than a milli-instant. As soon as
those particular problems were found, it was expected that Larry would be
able to produce a new version. Unfortunately, as I'm sure you're well
aware of, life doesn't always work the way it is supposed to.

| 5.001m, for example (I think), was a requirement for a particular
| version of PerlTk, and some other packages, but there was no way to use
| "require" to force it. The various patch releases are/were the only de
| facto releases for months at a time.

Yes, this was unfortunate. As someone already pointed out, there were a
lot of instances where people wanted specific things before 5.002 could
come out.

| One of two things should happen: 1) don't publish the patches until
| they can be consolidated into a tested mini-release, 2) continue
| publishing the alphabetic patches, but create much more frequent
| official releases that incorporate them. It doesn't make any sense to
| have the only usable releases "unofficial".

Actually, the third thing is what should happen, and was always planned to
happen: official patchlevels should be turned out more frequently. I guess
that's kind of 1), but not exactly. The lettered patches have always
(since alpha 3 or 4 or there abouts) been development patches, and were
usually fairly quick "Here's a patch that is really needed before the next
release. Try it out." Unfortunately, that didn't happen on 5.001[a-o].

Remember, you are talking about a "public domain" spare-time project, not a
real development environment.

-spp

On Thu, 7 Dec 1995, Eric Arnold wrote:

> One of two things should happen: 1) don't publish the patches until
> they can be consolidated into a tested mini-release, 2) continue
> publishing the alphabetic patches, but create much more frequent
> official releases that incorporate them. It doesn't make any sense to
> have the only usable releases "unofficial".

You must be coming late to the list. #2 is precisely what I'm trying to do
with 5.002. It may not be happening as quickly as some would like, but please
remember that I have a full-time paying job doing stuff other than Perl.

Andy Dougherty doughera@lafcol.lafayette.edu

> From: Andy Dougherty <doughera@lafcol.lafayette.edu>
>
> On Thu, 7 Dec 1995, Eric Arnold wrote:
>
> > One of two things should happen: 1) don't publish the patches until
> > they can be consolidated into a tested mini-release, 2) continue
> > publishing the alphabetic patches, but create much more frequent
> > official releases that incorporate them. It doesn't make any sense to
> > have the only usable releases "unofficial".
>
> You must be coming late to the list. #2 is precisely what I'm trying to do
> with 5.002. It may not be happening as quickly as some would like, but please
> remember that I have a full-time paying job doing stuff other than Perl.
>
> Andy Dougherty doughera@lafcol.lafayette.edu

And I'm sure I speak for all the perl5-porters what I say that I'm *hugely*
grateful for the very considerable time and effort that you've put into
this work.

Thanks Andy.

Tim.

> From: Tim Bunce <Tim.Bunce@ig.co.uk>
>
> > From: Andy Dougherty <doughera@lafcol.lafayette.edu>
> >
> > On Thu, 7 Dec 1995, Eric Arnold wrote:
> >
> > > One of two things should happen: 1) don't publish the patches until
> > > they can be consolidated into a tested mini-release, 2) continue
> > > publishing the alphabetic patches, but create much more frequent
> > > official releases that incorporate them. It doesn't make any sense to
> > > have the only usable releases "unofficial".
> >
> > You must be coming late to the list. #2 is precisely what I'm trying to do
> > with 5.002. It may not be happening as quickly as some would like, but please
> > remember that I have a full-time paying job doing stuff other than Perl.
> >
> > Andy Dougherty doughera@lafcol.lafayette.edu
>
> And I'm sure I speak for all the perl5-porters what I say that I'm *hugely*
> grateful for the very considerable time and effort that you've put into
> this work.

I also am somewhat in awe of the work being done on a free,
extracurricular basis. So, the question is, will it place unreasonable
pressure on Andy, et al, to get official releases out fast enough that
the world won't spend a greater proportion of time running on
unofficial patch releases, as has been the case? If it is
unreasonable, why not just say "uncle", and when a particular patch
release looks particularly tasty, make it official, and give it a real
rev. number. Perl5.001m could easily have been called 5.002. Why put
yourself in a position of having to say

It may not be happening as quickly as some would like, but
please remember that I have a full-time paying job doing stuff
other than Perl.

A little breathing room can be pleasant. The problem with official releases
is the never ending stream of incoming patches to be included.

-Eric

> From: Tim Bunce <Tim.Bunce@ig.co.uk>
>
> > From: Andy Dougherty <doughera@lafcol.lafayette.edu>
> >
> > On Thu, 7 Dec 1995, Eric Arnold wrote:
> >
> > > One of two things should happen: 1) don't publish the patches until
> > > they can be consolidated into a tested mini-release, 2) continue
> > > publishing the alphabetic patches, but create much more frequent
> > > official releases that incorporate them. It doesn't make any sense to
> > > have the only usable releases "unofficial".
> >
> > You must be coming late to the list. #2 is precisely what I'm trying to do
> > with 5.002. It may not be happening as quickly as some would like, but please
> > remember that I have a full-time paying job doing stuff other than Perl.
> >
> > Andy Dougherty doughera@lafcol.lafayette.edu
>
> And I'm sure I speak for all the perl5-porters what I say that I'm *hugely*
> grateful for the very considerable time and effort that you've put into
> this work.

I also am somewhat in awe of the work being done on a free,
extracurricular basis. So, the question is, will it place unreasonable
pressure on Andy, et al, to get official releases out fast enough that
the world won't spend a greater proportion of time running on
unofficial patch releases, as has been the case? If it is
unreasonable, why not just say "uncle", and when a particular patch
release looks particularly tasty, make it official, and give it a real
rev. number. Perl5.001m could easily have been called 5.002. Why put
yourself in a position of having to say

It may not be happening as quickly as some would like, but
please remember that I have a full-time paying job doing stuff
other than Perl.

A little breathing room can be pleasant. The problem with official releases
is the never ending stream of incoming patches to be included.

-Eric

> From: Eric Arnold <Eric.Arnold@corp.sun.com>
>
> I also am somewhat in awe of the work being done on a free,
> extracurricular basis. So, the question is, will it place unreasonable
> pressure on Andy, et al, to get official releases out fast enough that
> the world won't spend a greater proportion of time running on
> unofficial patch releases, as has been the case?

It has been stated several times that that is the plan. You may
remember references to 'whiplash inducing faster release cycle'
and 'patch pumpkin'.

Tim.