Joel Berger

I did not know that just by including it in the bin directory would install it. If nothing else I think the “standard” place is the script directory (as much as we can talk about “standard” and I think all 3 installer tools require that the author actually declares which scripts she wants to be installed.
For ExtUtils::MakeMaker it is the EXE_FILES key.
For Module::Install it is the install_script key.

After some digging I see (in Module::Build::API) that Module::Build will, by default, install every script found in the bin directory and one can specify the names of the script one-by-one using the script_files flag.

It’s a quite easy task if you just need to conform with your own code (for locating and parsing the version stuff I mean). Not quite re-usable, but I’m doing the same thing with http://bit.ly/HPRw7r

Yes, perl-reversion might perform a simple task, but I consider it an important part of my release process. Invaluable for multi-module releases; but I tend to use it to bump version even for single-module releases.

Remember, some folks only bump the version number of modules that have actually changed, which is valid as well. I generally have a distribution version associated with the primary module, which changes for every release, and bump the version of other individual included modules to the package version only when they change. Even though My::Module may have just had a major release, you know that My::Module::X remains the same.

When I make my first change to a module for a new release, I append _1 to the version and at release time, all versions with _1 will be updated.

Nick: that makes sense from an abstract perspective. But if you look at its effect on the toolchain, you will find it is actually a bad idea.

• It makes dependency resolution tricksier.

  (For background: if you only use a sub-module of a distribution you should only declare a dependency on that module – not on the main module of the distribution (i.e. you want to depend on LWP::UserAgent, not on LWP). Distributions get split or merged sometimes, or even renamed. If you declare your dependencies properly, the index will automatically compensate for such changes.)

  If every module of a distribution has a separate version, then declaring a dependency on a particular version of it will not guarantee you that the user code will be working against a particular version of the distribution as a whole. That matters because even when the user code only loads a particular module and version, the exact behaviour of that module may change implicitly depending on the precise versions of the other modules it ships together with.

  By having separate versions for each module, you are either forcing downstream modules to first be aware of exactly which set of versions of modules from your distribution (aside from the module on their use line) will provide the behaviour they depend on, and secondly to encode that information in their dependencies – both of which are, effectively, violations of encapsulation. Or else you are forcing them to declare their dependencies the fragile way – by depending on your distro’s main module, in order to get a guarantee about which version of the distro they will work against.

• It makes it difficult to reconstruct from the files in a perl installation exactly which distributions were installed in it, for precisely the same reason as the above.