Manipulate Dev. release number properly

[Robin Lee]

We can use the v-string feature provided by Perl itself to normalize the
version numbers of CPAN module rpms. We always convert the legacy decimal
versions to normalized v-string, and use the v-string number as the rpm
version, since v-string is friendly with rpm and also works within the Perl
world.

We can get a normalized v-string like this:

Perl> require version;
1
Perl> version->parse(1.94_56)->normal
v1.945.600

So the rpm version of perl(CPAN) should be 1.945.600 , and the one of
perl(Moose) should be 1.120 .

And we can even enhance rpmbuild, so when we deal with unstable CPAN
modules, we can tell it to keep or discard the numbers after the underscore
in specfiles. Or we can think out a more sophisticated guideline for
versioning rpms of unstable CPAN modules.


Cheers.
Robin

On Wed, Feb 23, 2011 at 5:31 PM, Paul Howarth <paul at city-fan.org> wrote:

> On 23/02/11 02:21, Robin 'cheese' Lee wrote:
> > Hi!
> >
> > RPM doen't generate proper version numbers for Dev. releases of modules.
> For
> > example, perl(CPAN) of f14 is actually 1.94_56 which just means 1.9456.
> But
> > the version generated by RPM is 1.94, much smaller than the actual
> version.
> > So I hope RPM can manipulate the underscores in version numbers properly.
>
> perl module version numbers are usually real decimal numbers rather than
> the hierarchical version numbers that are mostly used elsewhere and by
> rpm. So for instance a perl module version 5.2 would be newer than its
> 5.15 version but rpm would think that 5.15 was newer than 5.2. So
> underscores are not the only things to worry about with perl version
> numbers.
>
> It sometimes makes sense to separate the rpm and upstream version
> numbers so that the rpm upgrade path is maintained. The tidiest way is
> probably to pick a number of decimal places to use and stick with that
> for all rpm versions, and if upstream does a release where your chosen
> number of decimal places would result in the same rpm version number,
> just bump the rpm release instead. The alternative is to bump epoch
> whenever necessary to maintain the upgrade path when using the upstream
> version numbering scheme.
>
> We generally try to avoid packaging dev/trial versions of perl modules,
> so the underscore issue doesn't come up that often, but sometimes it's
> necessary. I doubt that rpm is likely to change its treatment of
> underscores so I think you just need to take care with versioning just
> as is necessary with other aspects of perl module versioning (including
> versioning of perl(...) provides, which have the same issues as the perl
> modules themselves).
>
> Paul.
> --
> Fedora Extras Perl SIG
> http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
> perl-devel mailing list
> perl-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/perl-devel
>