Alternatives to version numbering

[Toby Corkindale]

On Thu, Jan 03, 2008 at 04:54:51PM +0100, Abigail wrote:
> On Tue, Dec 11, 2007 at 02:22:25PM +1100, Toby Corkindale wrote:
> > 
> > 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?
> 
> No.
> 
> If I get a module from CPAN, and it says it needs 5.8.8, and I have 5.8.1,
> I'm pretty certain it ain't going to work. Doesn't take much effort,
> easy to check. OTOH, the module may list its 1320 pieces of Perl it
> uses. Do you really think I would bother checking each and every piece
> of functionality?  Of course, the module author could say "5.8.2 and this
> dozen pieces of functionality", but that's just the worst of both worlds.

Yeah.. the simple version number is, well, simple and effective.

I was just wondering about the case in the real world where we're seeing
vendors provide all sorts of specific patches to things though..

Also, as things fork, version numbers only keep their meaning to a specific
branch. Perl's development doesn't tend to fork, but some side projects can -
especially if you're working with source control systems like Git where it's
encouraged. I'm wondering about a system that could deal with knowing that
Tom's version doesn't support feature X, but Harry's version does.

Toby