> You are, however, ABSOLUTELY going to break forwards compatibility. You > were right, I did mean forwards. > > And this is just as bad. > > Let's look at the alternatives then. > > We're adding new stuff to META that old-spec consumers won't understand. > The two alternatives are to put it somewhere where they won't see it and > thus will silently ignore it, or to put it somewhere where they'll choke on > it. Since we're talking about "requirements", and not "the author's > favorite color", I suggest it's better to >
(I assume you meant somewhere they'll choke on it) Let me clear exactly what we are adding. We are adding non-canonical ADVISORY meta-data. As such, while clients MAY act on the basis of it in contexts outside of actual module installation (or if dynamic_config: 0 is set) if they so choose, it will not be the primary mechanism for enforcing the version. That will continue to be the Makefile.PL or Build.PL as per normal. Otherwise, see the last paragraph of > http://en.wikipedia.org/wiki/INTERCAL_programming_language . > > Also, breaking forwards compatibility is most certainly NOT just as bad - > the whole principle of "minimum version number" requirements for anything, > for instance, is built upon it. And there's a special word for a system > that never breaks forward nor backward compatibility: static. That's just > one step away from dead. > Fortunately, META.yml is not code. It's just data. XML/SGML is probably a better analogy. In XML, consumers are supposed to discard information they don't understand. This is quite normal. If a META.yml consumer for some reason didn't understand requires: this would not be a big deal. It would skip over it, the Makefile.PL would run, and the canonical source of the dependencies would catch it. This is exactly the same as what perl_requires will do. And we're not NEVER breaking forwards compatibility, it's just that breaking forwards compatibility should be a last resort when there is absolutely no other options, not something we do to encourage compliance.
