You have several options:

• Provide a method in your module such that your program can call it, and set the variable
• Pass the parameter with the "use statement" i.e. "use mymodule qw/3.0/;" Then the 3.0 will be passed to the import method of your module.
  But you need to be aware that this again happens before your program executes, so dont pass anything that is not a constant and available at compile time.
• Make an "our" variable in your module (our $VER), and explicitly set it in your program via $ModuleName::VER = "0.3" (not recommended)
• I'm sure Other monks will jump in here and provide more.

I think that is a very bad idea. A module should be (as much as possible) self-contained and know its own version number. If somehow other scripts need to know the version number of a module, there should be a variable or method available in that module to provide the version number. Look at many modules on CPAN: they have their version number stored in a $VERSION variable.

But perhaps I misunderstood you or perhaps you have a very good reason to externally save the version number, but then you will have to explain it more clearly.

Don't use global variables. Global variables are a symptom of a wider problem: global state.

Instead of relying on modules/subs picking up data from some sort of global place, you should pass the data to the function as a parameter.

# this is bad...
#
sub do_something {
   if ( $MyApp::VERSION < 1.0 ) {  # a global
      do_something_simple();
   }
   else {
      do_something_complex();
   }
}

do_something();

# this is good...
#
sub do_something {
   my ($version) = @_;
   if ( $version < 1.0 ) {  # a local variable
      do_something_simple();
   }
   else {
      do_something_complex();
   }
}

do_something(1.2);
[download]

Eventually you may find yourself passing around quite a few bits of data like this (a version number, maybe a database handle too, and a filename for writing output):

use v5.14;
use warnings;
use DBI ();

package MyApp {
   
   sub do_something {
      my ($version, $dbh, $output_file) = @_;
      if ( $version < 1.0 ) {  # a local variable
         do_something_simple($output_file);
      }
      else {
         do_something_complex($output_file, $dbh);
      }
   }
   
   sub do_something_simple {
      my ($output_file) = @_;
      open my $fh, '>', $output_file or die;
      print $fh "Hello world\n";
   }
   
   sub do_something_complex {
      my ($output_file, $dbh) = @_;
      open my $fh, '>', $output_file or die;
      print $fh "Hello world\n";
      printf $fh "There are %d rows in the table.\n",
         $dbh->do("SELECT 1 FROM my_table");
   }
}

MyApp::do_something(
   1.2,
   DBI->connect("dbi:SQLite:dbname=myapp.sqlite"),
   '/tmp/output.txt',
);
[download]

It can become cumbersome to pass them around from one function call to the next, and tricky to keep track of which functions need access to which data. That's where object-oriented programming becomes handy:

use v5.14;
use warnings;
use DBI ();

package MyApp {
   use Class::Tiny qw( version dbh output_file );
   
   sub do_something {
      my $self = shift;
      if ( $self->version < 1.0 ) {  # an object attribute
         $self->do_something_simple;
      }
      else {
         $self->do_something_complex;
      }
   }
   
   sub do_something_simple {
      my $self = shift;
      open my $fh, '>', $self->output_file or die;
      print $fh "Hello world\n";
      close $fh;
   }
   
   sub do_something_complex {
      my $self = shift;
      open my $fh, '>', $self->output_file or die;
      print $fh "Hello world\n";
      printf $fh "There are %d rows in the table.\n",
         $self->dbh->do("SELECT 1 FROM my_table");
      close $fh;
   }
}

my $app = MyApp->new(
   version      => 1.2,
   dbh          => DBI->connect("dbi:SQLite:dbname=myapp.sqlite"),
   output_file  => '/tmp/output.txt',
);
$app->do_something;
[download]

Any suggestions?

version numbers based on %ENV don't make sense -- I would rethink that (:in other words stop it :)

I strongly agree with tobyink here.   The design-issue here is not so much “that global value,” nor how or when it is represented or set, but rather, what and where you do something with it.   Every “what” that you do with it, should be in exactly one “where.”   And that should be ... a set of subroutines, located in just one place, which accept parameters, validate those parameters, and then return a finished work-product (which by-the-by uses this globally-assigned value).

It is also good to “future-proof” your design, writing apparently-redundant subroutines that presently return the same value, but which are named and called based on the meaning of whatever it is that they do.   Two different meanings – use cases – might return identical values today, but they might not do so tomorrow.   Anticipate this early.

The real problem with “global values” is that the logic which actually does something with those values is now scattered to the four winds.   You wouldn’t believe how hard it can be just to move an ill-designed application to a new location having a slightly different subdirectory structure ... because, since the logic to do it is everywhere, therefore dependencies are also everywhere.

In your app, what exactly is $ver_dir for?   I presume that the application will use this to obtain the name of some files, given the file name.   Therefore, write a single routine that does that ... and that checks the name for accuracy, and maybe that checks that the file exists, and so on.   Whatever it is that you do with $ver_dir, do it right here in one module and do it suspiciously:   let it be what will detect that bug.   Write a separate routine for each significant use-case even if each does the same thing.   I can confidently cut many thousands of dollars from the analysis-phase of a legacy project that we’re inheriting, when I see coding-practices like that (instead of what I usually see).