>>>>> On Mon, 16 Jul 2007 11:23:36 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said:
> # from John Peacock > # on Monday 16 July 2007 03:18 am: >> think I can justify adding such a special case to the version.pm code >> more than adding it to a consumer of that code (e.g. M::B itself). > I'm not sure that's justified either. Andreas? What does it need to > do? Somebody must maintain some piece of code that lets Module::Build do its work on bleadperls between 23190..25414. Please do not underestimate this corridor, it represents over 2000 patches in the time span between 2004/08/04 and 2005/09/14. One year, one month, and ten days of collective work. Currently Module::Build does not work in this corridor because version.pm refuses to work there. Somebody should really maintain glue code to close that gap. I would not mind taking the burden but I'd say the best place to do so would be version.pm itself because version.pm will change over time and every patch maintainer will have to closely follow its lead. So if John sees a solution within version.pm itself this is great news because half a year ago this seemed unfixable :-C But if John doesn't find a solution within version.pm, I'd consider it a good solution that Module::Build accepts my patch because Module::Build will continue to develop over time and people will use new features and some unrelated parts of their code will break and we will want to trace the bugs back to the origin. This is quite a bit different from survival kits for other outdated software because Module::Build is build software, not just an ordinary dependency. Every MB user can be affected on every future release. So if you want to convince people that it's a good idea to switch to Module::Build, make sure that it is backwards compatible down to 5.6.x without a gap. Sorry if my idioms are confusing. -- andreas