I'd leave most of the things out of the BEGIN blocks because most of them will already happen at compile time.

I'd do this for an OO module

package My::Package;
use strict;

use vars qw( $VERSION );
$VERSION = 0.01;

# If you inherit from some other module (use sparingly):
#use base qw( ... );
[download]

or, if you use inheritance (I've become more suspicious of base.pm even though I hardly ever use it since I hardly ever use inheritance in Perl):

package My::Package;
use strict;

use vars qw( $VERSION @ISA );
BEGIN {
    $VERSION = 0.01;
    @ISA = qw( ... );
}
[download]

where the BEGIN block shouldn't be needed for "normal" module situations but can be useful in unusual situations (that are often better to just avoid).

For a non-OO module:

package My::Module;
use strict;

use vars qw( $VERSION @EXPORT_OK %EXPORT_TAGS );
BEGIN {
    $VERSION     = 0.01;
    @EXPORT_OK   = qw( ... );
    %EXPORT_TAGS = ( ... );
    require Exporter;
    *import = \&Exporter::import;
}
[download]

where (again) the BEGIN is usually not needed. Remove %EXPORT_TAGS if you don't use it (it is useful if your module supports exporting groups of symbolic constants).

Inheriting from Exporter to just get an import() is a bad idea. It means you get *all* methods that Exporter defines even the ones you didn't even know about. This over-use of inheritance has lead to lots of modules using "autoloading" w/o having been designed to use autoloading which means that a simple mispelling of a method name gives a cryptic error about not finding some "*.al" file (which makes you think you've installed the module incorrectly rather than that you've mispelled a method name).

I don't use our, it makes code less backward compatible, it is confusingly complex (though often doesn't appear that way on the surface), and it is easy to abuse.

You can also add "use warnings;" after "use strict;", though there are also good reason to not do that. I'm a big fan of warnings being on during development but leaving them on in production is a net loss in my book unless you do the hard work of setting up the back channel so that the information from the warnings gets back to the developers and does't annoy the users. (And warnings.pm isn't included in versions of Perl that have now become rather old.)