On Tue, Jan 20, 2004 at 10:26:30AM -0500, Mark Stosberg wrote:
> On Tue, Jan 20, 2004 at 12:23:09PM +0000, Fergal Daly wrote:
> >
> > Not that this would ever be agreed upon, the old way is ingrained. Modules
> > will continue to do for example
> >
> > PREREQ_PM => { Parse::RecDescent => 1.80 }
> >
> > then fall over because 1.90 satisfies this requirement but is not actually
> > compatible,
>
> This is addressed to some degree in the Module::Build system, which allows you
> to specify required module versions like this:
>
> Ken::Module => '>= 1.2, != 1.5, < 2.0',
>
> So there /is/ currently way to specify exactly which versions you expect
> to be compatible. Unfortunately, unless the author of the required module
> has made clear version numbers like you suggest...it make take some
> digging to figure out exactly which versions should be required.
The big problem is that when I release a module requiring Ken::Module >=
1.80, I don't know in advance that the not yet released 1.9x is going to be
incompatible with it. I won't find that out until I start getting bug
reports about it.
If I was really being diligent, I would track all the releases of
Ken::Module and all your other dependencies and keep updating the
Ken::Module => '>= 1.2, != 1.5, < 2.0',
entry in my Build.pl.
The problem is the conflict within the current interpretation of version
strings:
You should say >= to get future bug fixes but...
You shouldn't say >= because you'll get future interface and behaviour
breakage.
This is caused by trying to cram 2 version numbers into a single version
string with no separator. Our tools cannot tell where the interface version
ends and the bugfix revision version begins.
What is the purpose of the version number? Given 2 versions of the same
module, my automated tools (like CPAN etc) and I should be able to
1. see easily whether each module is compatible with my software
2. know which one is "better" where "better" usually means later stable
revision but if I want it could take devel version into account etc.
A simple convention would be to reserve the final component for the
revision/bugfix version, but that might be a bit limiting. It may be better
to clearly separate them like 2.3.4_5.5 . Our tools could then pick up bug
fixes but ignore interface breaking releases, all without constant rewriting
of our (increasingly complex) PREREQ_PM lines.
If we want to get really fancy, in the meta information for Module::Ken
2.3.4_xx we could declare that this is in fact compatible with 2.3.2 (maybe
we decided that the interface change in the 2.3.3 series was a mistake and
have abandonned that branch). Now Module::Fergal, which thinks it wants the
latest 2.3.2_xx, knows it can happily use 2.3.4_xx, which means Fergal
doesn't have to update his Makefile.PL every time Ken releases a new version
and Ken doesn't have to keep backporting bug fixes to 2.3.2. to keep Fergal
happy.
And of course if we get even more fancy, this meta data can be very easily
used to build a tree of compatibility. So if 2.3.2 had declared itself to be
compatible with 2.1.0 then CPAN can easily figure out that 2.3.4_xx is also
an acceptable substitute for 2.1.0.
Anyway, forget about the fancy stuff. It sucks that unless I keep checking
my dependencies and updating my Makefile.PL, my modules are going break some
day, just because something I depend on broke compatibility. When that does
happen, I'll have to go to search.cpan.org and root out the old compatible
version by hand. That's a problem that cannot be solved with a single
version number,
F
