Um, it is backward compatible, and it should be: require 5.006; It just isn't forward compatible, as few things are.

Actually, in this case it must be: use 5.006; require is a runtime statement, but if we're using 5.6.0 syntax we need the version check at compile time. Compare these two examples, one with require and one with use, and their results with perl5.005_03:

#!perl

require 5.006;
use strict;

our $var = 7;
__END__
Global symbol "$var" requires explicit package name at tmp.pl line 4.
Execution of tmp.pl aborted due to compilation errors.
[download]

#!perl

use 5.006;
use strict;

our $var = 7;
__END__
Perl 5.006 required--this is only version 5.00503, stopped at tmp2.pl 
+line 1.
BEGIN failed--compilation aborted at tmp2.pl line 1.
[download]

I believe I was correct when I said 'non-backward compatible'; I was referring to the use of version strings with require/use, as in require 5.6.0;. That feature is forward compatible (future versions of perl5 will support version strings) but not backwards compatible (past versions of perl do not support version strings).

Good point on use vs. required.

For version strings to be non-backward-compatible, they would have to not support the previous method for doing versions strings. The previous method looks like "5.005_03", and this is still supported by use and require. If use only supported the new syntax, then that would not be backward compatible.

Future versions of Perl supporting something old is called backward compatability. The "future" vs. "backward" adjective must be applied to the scripts (data), not to the inerpreter (program) in order to match the "compatability" adjective.

Alternately, you could say that your script that does use 5.6; isn't backward compatible. And you'd be right to be upset about that, but you have to blame the script author not the Perl developers for that. (:

        - tye (but my friends call me "Tye")