On Nov 18, 2007 9:27 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote: > David Golden wrote: > > So, yes, it was a crappy design decision/hack, but now we're stuck with it. > > No, we should not wedge ourselves into a corner like this. Preventing a > better way of doing it from going into a protocol because there's a handful of > code that uses the old way is doomed to render protocol improvements > impossible. META.yml is versioned just to handle this sort of thing.
I think you're taking my quote out of context. My broader point was that adding a new key doesn't take away the need to support the hack. And adding a new key creates work. And, as you put it in your "5.5 not supported" email, this is volunteer work, not paid. This started because Adam said "[a]fter a number of incidents, it would appear..." without citing anything specific and there seems to be a bandwagon to go tinker because it's a better design. With no disrespect to Adam intended, I don't particularly want to go tinker with things just because "it would appear". I would bet that 99% of incidents are a result of Slaven Rezic doing CPAN Testers smoking on Perl 5.5.5 and blowing up code that didn't bother to specify 5.006 or where the code blows up because of "our $VERSION". For that case, we should ask a bunch of volunteers to go add code in the interest of "better design"? (And better design that still wouldn't stop Slaven from blowing up code on 5.5.5?) I'm not opposed to forward progress, but I'd like a more thoughtful analysis of the use case. > Furthermore, there's probably all of 2 or 3 pieces of code which actually > handles "requires: perl". CPAN, CPANPLUS and maybe PAUSE. That's going Nit: add CPAN::Reporter. > overboard on the backwards compatibility police to protect those. We're not > even talking about removing "requires: perl", just adding a better way. As long as we're talking about better ways -- let's consider how to reconcile this idea (and configure_requires) with dynamic_config defaulting to 1 if omitted. E.g. CPAN.pm ignores META.yml requirements if dynamic_config is 1 and only gets requirements after Makefile.PL or Build.PL runs. Oh, wait, except for configure_requires -- because that's needed before we can run those. So in one case dynamic config is ignored instead of honored. Presumably perl_version would not be subject to dynamic_config -- or should it? David