Alternatives to version numbering

Robert Rothenberg robrwo at gmail.com
Mon Dec 10 19:34:34 GMT 2007


On 10/12/2007, Toby Corkindale <tjc at wintrmute.net> 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).



> ... 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.

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];

# We want on of the branched versions with extra stuff:
> use Graph::Drawer {
>     WITH_TRUETYPE_SUPPORT => 1,
>     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?

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.


> I think that would be kind of neat, but I'm not sure how useful it would
> be in
> the long run.. Still, I wondered if there had already been some work on
> this,
> or even just any thoughts?


I don't think it's worthwhile.

There's more important meta-data that should be added to module
distributions, like whether it requires a C compiler, or external libraries,
or works/doesn't work with some versions of libraries, modules, etc.,
whether it uses traditional or inside-out objects, etc.

Rob


More information about the london.pm mailing list