http://www.perlmonks.org?node_id=643022

kyle has asked for the wisdom of the Perl Monks concerning the following question:

After a romp through some SuperSearch results (and a read through Perl Best Practices), I wound up coding my $VERSION like this:

use vars qw( $VERSION ); use version; $VERSION = qv( (qw$Revision: 1.1 $)[-1] );

...where $Revision: 1.1 $ is something that's maintained for me by the revision control system I'm using.

Recently, I decided to start using git for revision control (having written some Perl to replay my old history into it). Since git is distributed, it really can't give me revision numbers in files like CVS can, so I'm looking for a new way forward.

I'm far too lazy to remember to update one of those numbers every time I touch a module, but I would like them to stay up-to-date. How do others handle this? How do you get a worthwhile version number into your programs and modules without any discipline or other noticeable effort?

The only solution I've thought of is a local commit script. It would determine which files have changed since the last commit and update their version numbers before running a git commit. This wouldn't be too hard to implement, and the habit of using it wouldn't be hard to form. Even so, I'm wondering if there is an even better way. Can I slip in another few lines in place of my $Revision$ hack and get what I want?

All your wisdom will be greatly appreciated.

Replies are listed 'Best First'.
Re: Best Practice for automatic version numbers? (no, how)
by tye (Sage) on Oct 06, 2007 at 03:22 UTC

    Just because you didn't modify Foo.pm doesn't mean your version number doesn't need to change. Does your system handle that case?

    If I were going to automate version numbering then I'd likely put the version number outside of Foo.pm (into a file just for the version number) and patch my "make dist" step to increment the version number in that file after the distribution is written.

    I'm not tempted to automate this since doing it manually is such a tiny part of what it takes to make a release. I certainly won't be tieing some internal revision control number to the module version number, as that adds ugliness to the version number and adds an internal-to-external tie, something that often leads to complications.

    - tye        

      It's easy enough to force a version number to change if it needs to.

      I think you're right about the dubious value of using revision numbers as version numbers, but I'm confident these numbers aren't used for anything. I thought they might be useful at some point, but I never found that point, and the code in question isn't used by anyone else.

      So this may be my big chance to get rid of something that's not needed. Still, I'm curious, since this seems like something that ought not to require the amount of effort that it does.

      Thanks for your thoughts.

Re: Best Practice for automatic version numbers?
by perlfan (Vicar) on Oct 06, 2007 at 03:19 UTC
    As far as I am concerned, the "version" in the PM does not correspond to the revision number in your version control. The VERSION of a module should correspond to a release process of some sort that, so it seems to me that you'd want to only update that once you go from a bleeding edge version (or bug fixing branch) to some sort of actual release.

    That said you could create a simple wrapper around whatever your commit command is that looks at file defining the module version, reads it, then automatically increments it in some predetermined way. In general, though, it is a bad idea for the commit process of your version control to modify the code in a non-obvious way - no matter what version control you are using.