On Thu, Jan 10, 2013 at 10:06:10AM -0600, John M. Gamble wrote:
> Yeah, after dithering about it for a few days, I went with the philosophy
> that the package has the version, not the individual modules. For the
> simple reason that the package as a whole is what's being developed, from
> the documentation to the scripts to the README file to, of course, the
> actual modules themselves.
For what it's worth, my own opinion goes in that direction as
well. For a long time, I was in the "one version per module in the dist"
camp, but then I realized, on top of the arguments given by John that:
a) In real life, I never saw any user actually care about
per-module changes (as, as mentioned above, it's the holistic dist
blob that matters).
b) and if anyone would care about what files exactly have
changes from one release to the next... well, there's the
repositories for that (and if there is no public repositories,
that's nothing that 'git-cpan --backpan import' can't solve)
c) it also simplify things when you want to specify versions in
use statements. Using Foo::Bar in code A, and Foo::Baz in code B? If
they are both from dist Foo and its version is 1.23, then you'll have
consistent 'use Foo::Bar 1.23' and 'use Foo::Baz 1.23' (and although,
true, you could do 'use Foo 1.23', there are cases of main module Foo
where you wouldn't want to do that).
So, yeah, I've embraced the per-dist version, and
have lived happily ever after...
Now, numerical version or semantic version format... that's
an altogether more entertaining can of worms. ;-)
Throwing my 2 cents in,
`/anick
--
