Eric Wilhelm wrote at Wed, February 20, 2008 12:37 pm:
> I think it might be better to just set them all at the same version
> number or else break them into separate distributions. This would make
> it easier to report bugs and diagnose remote problems because all you
> have to do is check the most recent dist version rather than consult a
> table of "most recent shipped versions per-module".
But then you wind up with different versions of a module where the only
difference is the version number (because you have to update the version
number even when you didn't make any changes to the module in that
release).
There isn't really an ideal solution to this problem. My choice is this:
When I update a module, it gets the version number of that release. If
there are no changes in a particular module, it retains the version number
of the last release in which it was modified.
>>Is it safe to set $self->{properties}{dist_version} like that, or do I
>>need to override the dist_version method also?
>
> Well, it hinges on some details in the internals, and whenever you do
> that, you have to accept the associated fragility.
I think I'll go ahead and override the dist_version method, which should
be a little less fragile. That still depends on process_xs using
dist_version. But if that ever changed, it would almost certainly be to
use the version number from the corresponding .pm file, which is what I
want anyway.
> Also, in general it is better to use local() for dynamically scoped
> overrides to hash values.
I hadn't realized that you could localize hash values in a lexically
scoped hash. (I thought it only worked with package-scoped variables.)
But you're right, that does work.
> But, probably simplest/easiest to just go with the grain.
But, I'm stubborn. :-)
--
Chris Madsen [EMAIL PROTECTED]
-------------------- http://www.cjmweb.net --------------------
