in reply to $VERSION in module files

See my reply in the thread What basic things should I know about versioning modules? that a 1.23 style versioning should provide maximum compatibility, specified in a format of our $VERSION = "1.23";. Of course, TIMTOWTDI, and you'll see some modules use interesting versioning schemes and some modules use code to determine $VERSION like parsing it out of a VCS $Revision$ string. See the documentation in ExtUtils::MakeMaker's VERSION_FROM and ExtUtils::MM_Unix's parse_version, but note that those are probably not the only tools that parse version strings out of module files, so I'd really only recommend our $VERSION = string;.

Replies are listed 'Best First'.
Re^2: $VERSION in module files
by bliako (Abbot) on Mar 26, 2020 at 10:46 UTC

    OK thanks. So, I must have a $VERSION var in EACH (package) file in the module. I must change those $VERSION strings manually each time. And I must change POD versions manually too. Right?

[reply]
[reply]

        perl-reversion works for me. It changed both our $VERSION and POD versions. Worrying thing is that it scanned bash files too... (just tried inserting a VERSION=0.21 in a bash script and perl-reversion bumped that version too. Definetely good to know but perhaps a bit dangerous.)

[reply]
[d/l]
[select]

      Not necessarily. If you maintain a version number for the dist which applies also to all the modules then you can pick one master module which all the others use and have them set their versions from that one. eg.

      package Foo;
our $VERSION = '1.01';

# ...

package Foo::Bar;
use Foo;
our $VERSION = $Foo::VERSION;

      [download]

      I never bother specifying version numbers in POD so you're on your own there. :-) Doubtless there's a way in Dist::Zilla but then you'd have $problems++

[reply]
[d/l]
[select]

        If you specify the module version like this, it won't be picked up by tools like ExtUtils::MakeMaker, and won't be properly indexed on CPAN by PAUSE. The version needs to be specified by a single line, and won't be able to load modules from the current distribution.

[reply]
        package Foo;
our $VERSION = '1.01';
# ...
package Foo::Bar;
use Foo;
our $VERSION = $Foo::VERSION;

        [download]

        If that's in a single file that may work, I'm not sure, however, I suspect at least some of the tools that rely on a static parse won't be able to handle that.

[reply]
[d/l]

        Not necessarily. If you maintain a version number for the dist which applies also to all the modules then you can pick one master module which all the others use and have them set their versions from that one. eg.

        inheriting a version number is like inheriting your fathers age/birthdate

        yeah my wife just gave birth to a beautiful baby, 9lbs, 32 years old

[reply]
[d/l]
      In Win32::Mechanize::NotepadPlusPlus, I added a rule in my Makefile.PL postamble, so that make populateversion will take the VERSION that the Makefile sees (which it grabs from the "primary" module in the dist, thanks to $mm_args{VERSION_FROM} ), and uses perl to do an in-place edit of the our $VERSION =... from the related modules. 

      # auto-populate the VERSION in the submodules from $(VERSION), which c
+omes from main module
populateversion :: lib/Win32/Mechanize/NotepadPlusPlus.pm
    $(NOECHO) $(ECHO) want to auto-populate VERSION in all sub-modules
+: $(VERSION)
    $(PERL) -pi -e "s/^(\s*our\s+.VERSION\s*=).*?;.*?$$/\1 '$(VERSION)
+'; # auto-populated from W::M::NPP/" lib/Win32/Mechanize/NotepadPlusP
+lus/Notepad.pm lib/Win32/Mechanize/NotepadPlusPlus/Editor.pm

      [download]

      So I just have to change the version in one master location, and then make populateversion (or, since I have other rules that depend on that rule, run one of those other rules for doing other documentation updates) to get the version in sync across the modules.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom