Alternatives to version numbering

Toby Corkindale tjc at
Tue Dec 11 03:22:25 GMT 2007

On Mon, Dec 10, 2007 at 07:34:34PM +0000, Robert Rothenberg wrote:
> On 10/12/2007, Toby Corkindale <tjc at> wrote:
> > Version numbers are a well-understood way of telling whether a perl
> > module, or
> > indeed entire application, has the features or behaviour you are looking
> > for.
> Really? How does 1.01 or 2.3.1 tell me anything about a module? Version
> numbers won't even tell me how many prior releases there have been (which is
> not a useful measure of anything anyhow).

It works by you, the reader, having realised that the features or fixes you
want were only available from version X onwards. You know that mod_perl 2.x
requires a different method of handling to mod_perl 1.0-1.3, and 1.99 is
different again.

As you pointed out - the version numbers on their own don't tell us very much
of interest at all. They require outside knowledge to make them meaningful.

What if you have a module that you want to use, and it says it requires Perl
5.8.8 - but you have Perl 5.8.1 with vendor patches on your system - maybe it
includes the fixes or functionality the module author wants? 
Wouldn't it be nice if their requirements had been expressed in a way that
dealt with that?

(Personally I strongly dislike the tendancy of vendors to make their own
bundles of Perl, kernels, gnome, etc. with loads of patches, as it does make it
hard to know what target to hit as a developer. However,it is what seems to
happen out there.)

> > ... Going back to Perl, we currently use a system in Makefiles of looking
> > for a
> > minimum required version.
> > But what if we have several branches of the module available? What if the
> > behaviour we desire is limited to a min/max range within a particular
> > branch?
> > In fact, what if we desire behaviour which is matched by various versions,
> > and
> > potentially more in the future that we're not yet aware of yet?
> Why do you want to do that to yourself? If different versions of the same
> module have radically different behaviours, then maybe it's time to start
> using a new module.

What if the changes are intended to be rolled into the head branch eventually?
(Ideally, changes should get their own little modules that plug-in seamlessly,
but not all architectures are ideal.)

> Wouldn't it make sense then to allow module version requirements to be
> > specified by some kind of desired-behaviour-specification?
> >
> > So you might end up with something like:
> > # we want a specific range of versions:
> > use perl {
> >     VERSION => {
> >         '>=' => 5.6.1 ,
> >         '<' => 5.9.0
> >     }
> > };
> Ugly syntax. Why not something like
>   use perl version => [5.6.1, 5.9.0];

Syntax could definately be improved; it's just concept-code(tm).

> # We want on of the branched versions with extra stuff:
> > use Graph::Drawer {
> >     WITH_GIF_OUTPUT => 1,
> > }
> Ok, so who is going to code meta-data about various modules? If it's the
> author, then what about the thousands of existing modules on CPAN?

Like most innovation, it would be optional adoption.

> I am concerned one could end up with something like this though:
> > use Another::Module {
> >     WITH_BUGFIX_10234 => 1,
> >     WITH_BUGFIX_11478 => 1,
> >     WITH_BUGFIX_14466 => 1,
> >     ... # repeat a LOT
> > }
> Yep. In most cases, features are added or bugs are fixed without affecting
> compatibility with prior releases.
> There are a few exceptions, and there are/is CPAN package(s) for keeping
> multiple versions of packages on your system.
> > so I'm not sure it'd work for ALL behaviours, but maybe at least work for
> > detecting if you had a few of the right patches in your current version.
> Usually I read through the module documentation to find out when a
> particular feature or bugfix that I care about was applied, and make that
> the minimum version.  Otherwise I do things like check the module for the
> presence of functions I require, and adjust accordingly.

Works fine for the simple use case, but I'm having to use a bunch of modules
with automatic versioning and a monolithic design and have been wondering about
potential solutions.. Not sure how other people deal with it, other than in an
ad-hoc manner.


More information about the mailing list