Re^4: why I will not use ActiveState again

it's difficult for me to determine that it's because a core module several layers up the chain is different

I think that point of yours (along with the rest of your post) is fair enough. And I also think that ActiveState's decision to modify the module is fair enough.

So ... let's get constructive about the issue ... what should they be doing (from the perspective of a module author) when they perceive a need to amend a core module ?

Cheers,
Rob

Comment on Re^4: why I will not use ActiveState again

Replies are listed 'Best First'.
Re^5: why I will not use ActiveState again (++$version) by tye (Sage) on Dec 02, 2006 at 16:09 UTC
Duh. You change the version number whenever you allow a change to any module to escape your tight little grasp. In the case of emergency changes, try to change the version number in a way that won't conflict with the next version that the real author of the module is likely already working on and will be releasing soon, before he notices that you've upgraded out of his control. I usually do this by incrementing by a smaller-than-usual amount (such as appending "001" to the end). - tye	[reply]
Re^5: why I will not use ActiveState again by xdg (Monsignor) on Dec 04, 2006 at 05:36 UTC
what should they be doing (from the perspective of a module author) when they perceive a need to amend a core module My two cents, At a minimum, make sure any thing that dies/carps mentions that it's a patched version of the module and bump/alter the version number. Better would be to get the patch taken upstream -- or, in this case, perhaps, get File::Path pulled out as a dual core/CPAN module so the patch could be made generally available in the "latest" release of the module on CPAN. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]