>>>>> 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

Reply via email to