Re^2: CPAN: Module version versus kit version

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).

Comment on Re^2: CPAN: Module version versus kit version

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^3: CPAN: Module version versus kit version
by NERDVANA (Priest) on Dec 09, 2024 at 18:44 UTC

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]