|
Re: CPAN: Module version versus kit version
by hippo (Archbishop) on Dec 05, 2024 at 22:18 UTC
|
Generally I (as an author) ensure that all modules within a dist (which you are calling a "kit" here) have the same version number and that version matches the dist. That way there is no ambiguity. Occasionally this means that more than one "version" of any given module may be identical, except for the version number. I'm happy with that anomaly as the price to pay for consistency.
It is also one of the kwalitee measures so I take that as something to aspire to. Other opinions are valid too, of course.
| [reply] |
|
|
| [reply] |
Re: CPAN: Module version versus kit version
by NERDVANA (Priest) on Dec 06, 2024 at 01:00 UTC
|
If you don't change the module version, it breaks things for various people.
One time I had a goal of shipping a collection of different modules in the same dist where the version of the module was the last change to *its* API. People complained that the versions were different from the package.
Another problem I've seen is when you change the number of digits in the dist, it breaks the mapping from CPAN version to Linux distro version, because the distros are taking our packages and giving them numbers like Foo-1.10.0-debian-5. Other distros choose Foo-1.100.0 by converting the full perl version as per Version.pm. As soon as you make the version number "1.10.1" all the distro maintainers have to manually get involved to decide what to do about it.
Anyway, it's not ideal, but if you want to cause the least problems for the most people, always use the same version for everything in the dist and never change the number of digits. Document the fact that nothing actually changed in the Changes file. | [reply] |
|
|
Wanting to only bump module version on API change sounds like a different (albeit legit) approach from "semver" (semantic versioning). I describe that as incrementing when (from least significant to most significant digit) you fix something, add something, break something. That approach would dictate that a version bump of some sort is recognised somewhat as a good idea even if one only makes an improvement to a module, without API change.
As a sidenote, I haven't felt the urge to use semver for PDL. If the major version incremented on every breaking change, it would probably be roughly on major-version 30 by now (including from before my time as maintainer).
| [reply] |
|
|
Actually I misspoke, I meant behavior change rather than API change. So yes I would bump the version for bug fixes too.
What I was trying to say is that I was basically shipping multiple modules that *could* have been their own dists. I wanted the versions to tell people that Foo::A 1.01 could be found in Foo-1.01.tar.gz or Foo-1.02.tar.gz or Foo-1.03.tar.gz, and a dependency on Foo::A 1.01 could be satisfied by any of those dist versions.
| [reply] |
Re: CPAN: Module version versus kit version
by SankoR (Prior) on Dec 05, 2024 at 17:28 UTC
|
You don't mention what you use to generate or upload dists but you could simply upload the tarball with any name you like to get around PAUSE's dup filters. Even without changes, I suggest you change the version of the dist's main package so PAUSE indexes it as a newer release and CPAN clients correctly install your latest release by default. | [reply] |
Re: CPAN: Module version versus kit version
by syphilis (Archbishop) on Dec 06, 2024 at 01:16 UTC
|
Whenever that's happened to me (and it's happened a few times), I just bump the version of the .pm file(s) and upload a new distro (with a matching version number) to PAUSE.
I reckon I've seen plenty of others adopt the same approach, and there's no rule that Foo.pm version 1.11 has to be different from Foo.pm version 1.10, apart from the different $VERSION settings, of course.
ASIDE:
There used to be a recommendation (might still apply - dunno, don't care) that version numbers in pm files be specified like:
our $VERSION = '1.10';
$VERSION = eval $VERSION;
When you do that, the condition $VERSION eq '1.10' becomes untrue, owing to the terminating '0' :
Owner@DESKTOP-88J497T ~
$ perl -e 'our $VERSION = "1.10"; $VERSION = eval $VERSION; print "WTF
+" if $VERSION ne "1.10";'
WTF
Owner@DESKTOP-88J497T ~
$ perl -e 'our $VERSION = "1.11"; $VERSION = eval $VERSION; print "WTF
+" if $VERSION ne "1.11";'
Owner@DESKTOP-88J497T ~
Needless to say, I therefore don't do that "eval", but I now also avoid specifying a version number that ends in 0 - just in case.
These days, my module would go (eg) from version "1.09" straight to "1.11".
Cheers,
Rob | [reply]
[d/l]
[select] |
|
|
| [reply] |
Re: CPAN: Module version versus kit version
by ikegami (Patriarch) on Dec 06, 2024 at 17:47 UTC
|
You didn't say what installer you use, but I'm going to assume it's ExtUtils::MakeMaker.
I presume you have something like the following:
VERSION_FROM => "lib/Foo.pm",
Replace it with the following:
VERSION => "1.10.1",
That will set the kit distribution's version to 1.10.1 without requiring a change to lib/Foo.pm.
That said, there's no harm in simply bumping the module's version even if it's otherwise unchanged.
| [reply]
[d/l]
[select] |
|
|
That said, there's no harm in simply bumping the module's version even if it's otherwise unchanged.
Sure, you could do that, but the OP specifically asked not to.
Cheers,
Rob
| [reply] |
|
|
| [reply] |
|
|
|
|
|
