On Nov 25, 2007, at 9:20 PM, Adam Kennedy wrote:
On 25/11/2007, Ken Williams <[EMAIL PROTECTED]> wrote:
I agree that there needs to be some way of extending our notion of
prereq types from the 2 current types (module and 'perl'). I
disagree that it should be done in a backwards-incompatible way
though. The cardinal rule of syntax extensions must be kept in mind:
any new functionality must be a syntax/semantics error in the old
system, or else old parsers will continue on their merry way and do
The Wrong Thing.
I'd like to see some URIs that outline the logic behind this
"cardinal rule".
I thought this was common knowledge and obvious, but maybe I could
find some URIs. I'm just talking about the reason it's desirable
e.g. for perl 4 to fatally choke on "use File::Spec".
I'm generally against any solution that starts with "first, break
every existing tool", and maintaining backwards compatibility
wherever possible has long been one of the principles by which the
toolchain has been developed.
Try to at least represent my point of view fairly, and then we'll talk.
It was proposed on the list that we make a backwards-incompatible
change from "requires => perl => $version" to "perl_requires =>
$version". I was arguing against that change, and showing how we
could move things forward while entirely preserving backwards
compatibility.
Perhaps you really mean forwards compatibility but you think you mean
backwards. Are you worried about META.yml 1.2 parsers reading 1.4
specs, or vice versa? Those are completely different issues from
each other.
requires:
mod/Carp: 1.03
mod/File::Basename: 2.73
sys/perl: 5.005
sys/platform: Windows
bin/wget: 1.10
bin/gpg: 1.4.5
lib/tk: 8.4
lib/cups: 2
ext/mysql: 5.0
ext/openssl: 0.9.71
This idea was originally proposed a couple of years ago.
I don't remember that. URIs?
-Ken
