Re: CPAN: Module version versus kit version

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.

Comment on Re: CPAN: Module version versus kit version

Replies are listed 'Best First'.
Re^2: CPAN: Module version versus kit version by etj (Priest) on Dec 07, 2024 at 14:53 UTC
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]
Re^3: CPAN: Module version versus kit version by NERDVANA (Priest) on Dec 09, 2024 at 18:44 UTC
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]