Switch to SemVer versioning?

[nohuhu]

Makes sense IMO: https://semver.org. #23 gives enough enough reasons to bump minor version (API changes, backwards compatible).

The only kind of gotcha is that tne next semantically valid version will be 1.30.0, which is fine by me.

[TJC]

👍

[Grinnz]

1.30.0 is not a higher version than 1.26. Perl versions are translated between decimal numbers and dotted-decimal tuples by considering each segment to be 3 decimal places, so 1.26 is v1.260.0. It's easiest if you bump the major version when switching version schemes. Always use a leading 'v' in the string to avoid ambiguity. Don't use "vstrings" (the perl feature that looks like bareword versions but turned out to just confuse everything) - just use strings. And do not use underscores with version tuples, they were only recently fixed in version.pm and will behave differently in various versions of Perl. Since this distribution requires Perl 5.14 it should work reasonably well otherwise.

[Grinnz]

As a side note if you really want to use underscores with version tuples, I would add a configure requires dependency on version.pm version 0.9915 (see https://metacpan.org/source/JPEACOCK/version-0.9918/CHANGES#L38-44). But I'm not sure that will be foolproof.

[nohuhu]

@Grinnz Thanks for the advice, much appreciated. Switching to semver in a major version is something we can do I think, if @TJC has no objections. Otherwise it can wait, no big deal.

The reason I used underscores is to push a dev version to CPAN to get it smoked without forcing everybody to upgrade to potentially broken version. Is there another way to get the same effect without using underscores?

Also looking at the code I don't see "vstrings" used, it's just a string:

our $VERSION = '1.30.0_01';

Do you know a foolproof set of guidelines to follow with regards to Perl module versioning?

[nohuhu]

Huh, I'm confused. If 1.26 is translated to v1.260.0 then it sort of follows that "1.30.0" should be translated to v1.300.0? Or does it mean that by including a second dot in the string the translation is skipped and "1.30.0" is parsed directly to v1.30.0 tuple?

[Grinnz]

Well the most foolproof method is to use decimal versions and always declare them as strings :)

But on Perl 5.14+ version tuples should work well enough if you follow what I mentioned above. I just included the part about vstrings for completeness.

Aside from underscores, the way to indicate a dev release is to set 'release_status' to 'testing' or 'unstable' in the metadata, and add -TRIAL to the end of the tarball name. This is what dzil release --trial does: https://metacpan.org/source/DBOOK/lib-relative-0.001-TRIAL/META.json#L57 . However this metadata attribute requires meta-spec 2 which is not supported by Module::Install (the -TRIAL in the tarball name should be enough on its own, though). It's also recommended to not use the same version for a dev release as a non-dev release, of course.

[Grinnz]

The translation I mentioned is for translating decimal versions to dotted-decimal tuple versions. '1.30.0' is already a tuple version, since it has more than one decimal point (but you should also add the leading v for clarity).

[Grinnz]

The heuristic for which version type it's parsed as: https://metacpan.org/pod/version#PARSING-AND-COMPARING-VERSIONS

[nohuhu]

Oh-kay... This endeavor turns out to be way more complicated than I thought initially. :) Thanks for the pointers, I'll keep all this stuff in mind for the future. For now the status quo would suffice.

[nohuhu]

@Grinnz Since you were helping with my versioning blunders anyway, do you have an idea why release with version 1.27_02 is listed as "1.26 DEV" in Metacpan and marked red: https://metacpan.org/pod/release/NOHUHU/Test-PostgreSQL-1.27_02/lib/Test/PostgreSQL.pm? I was going to release 1.28 soon but now I'm wondering if that is going to work as expected.

[Grinnz]

That is because the META.json and META.yml you included have version 1.26 (https://metacpan.org/source/NOHUHU/Test-PostgreSQL-1.27_02/META.yml#L38). Make sure you are creating the release tarball using perl Makefile.PL; make && make manifest && make dist (I assume this is still the release procedure for M::I since the documentation doesn't say differently) so it includes the proper META.yml. However Module::Install doesn't support META.json so I'm not sure where that came from. @TJC any insight?

[Grinnz]

The DEV and red color are normal for trial releases however.

[TJC]

I'd be happy if someone can switch this lib to one of the more modern distribution modules.

Dist::Zilla always felt a bit over engineered for my needs, but I recognise that M::I is getting dated now.