But how about the reverse case?

use warnings;

use 5.6.0;

v-string in use/require non-portable at ./usenet-2008-5-11.pl line 5.

So you have to say

use 5.006;

#!/usr/local/bin/perl

use warnings;

use 5.010;

------ start quote -----
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:\>perl
say "hi";
String found where operator expected at - line 1, near "say "hi""
        (Do you need to predeclare say?)
^D
syntax error at - line 1, near "say "hi""
Execution of - aborted due to compilation errors.

c:\>perl
use 5.10.0;
say "hi";
^D
hi

c:\>perl
use 5.010;
say "hi"
^D
hi

c:\>perl
use 5.6.0;
print "hi\n";
^D
hi

c:\>

For the more general case there's the module Perl::MinimumVersion which
attempts to scan your source code and determine the minimum version of
Perl that is needed to run it. It's still in early development though.

Personally, I keep a cheat-sheet of which things (that I commonly use)
were added with each version of Perl. I created it by reading through
the perldelta pages in perldoc.

If there is any program available that can check through piece of code and
report any features that are new features of some subversion of perl5 and list
those it finds with of course the version of perl5 that has the feature?

Or am I safe to assume that users with older perl5 version that I have tested
my code with can run my program if I dont have any "use 5.xxx;" line and the
script runs fine?

I haven't started using 5.10 features yet. All of my servers have some
variant of 5.8.x installed, and until a significant portion of them has
been upgraded to 5.10.x (which I expect to come with the next release
of RHEL and Debian - but we won't upgrade all our servers immediately
even then) using 5.10 features is just a waste of time.

  PJH> In 5.10 you have to explicitely enable new features by adding a
  PJH> "use 5.010;" line.

  PJH> It depends on your programming style, of course. For my code it is safe
  PJH> to assume that it won't run with Perl 5.6.x or older unless I specially
  PJH> took care to make it portable. There were a lot of nifty features added
  PJH> in 5.8 and I am using them.

i haven't played with 5.10 yet and 5.8 didn't make major syntax
improvements that i want (though it is the default version i generally
use). but for some of my cpan modules (file::slurp) in particular) i
work hard to keep it backwards compatible all the way back to 5.005 (and
i think even 5.004). this is because it is a very popular module and
there are still too many places where old perl's lurk. i wouldn't do
this for any production code where i know the perl version is recent but
i can't control that when someone uses a module.

uri

The reverse case is pretty easy:

    BEGIN {
        die "Your Perl version is too new" if $] > 5.008008;
    }

<>  Suppose I write code on my desktop, which has perl 5.10.0 installed, and
<>  later transfer that code to a system that only has perl as far as 5.8.8.
<>  How can I cause an error on the desktop if I accidentally use any of the
<>  new features of 5.10.0, as I would want to do to signal incompatibility?

That's not the reverse case.

<>  Is this sort of thing impossible?

Basically, yes. There are some new features that aren't available unless
turned on explicitely, but that isn't the case for features that will not
cause any backwards compatability issues. For instance, there are a ton of
new features when using regexpes, and you get them regardless whether you
use "use feature" or not. Furthermore, bug fixes will be there as well, and
so will any modules that are in 5.010, but not in an older install of Perl.

The best way to avoid accidentily using features that aren't available on
older Perl is to install the oldest Perl you want to develop for, and test
with that.

   $ perl5.10.0 -e 'print $]'
   5.010000
   $ perl5.8.8 -e 'print $]'
   5.008008
   $ perl5.8.2 -e 'print $]'
   5.008002
   $ perl5.8.0 -e 'print $]'
   5.008
   $ perl5.6.1 -e 'print $]'
   5.006001

Little question: Since this is a floating point number, are there any
rounding-error considerations when making comparisons and such?

Also, is there a reason why 5.10's output pads zeros on the right-hand
end of the number?

  s> Little question: Since this is a floating point number, are there any
  s> rounding-error considerations when making comparisons and such?

those are all well within the float range but i bet they really are
strings. you can check this with some stuff in scalar::util.

  s> Also, is there a reason why 5.10's output pads zeros on the right-hand
  s> end of the number?

that is obvious. there is room for a subrelease number (as in all the
5.8 versions). 5.10.2 will likely have $] as 5.010002

uri