search

perlpunk / perl5-module-meta

Best Practices for Perl5 CPAN Modules Metadata
MIT License
18 stars 2 forks source link

Suggestion: Add a subsection to "versioning" for vendors #5

Open kentfredric opened 4 years ago

kentfredric commented 4 years ago

Its fine to encourage CPAN authors to use useful version schemes, but the reality is:

  1. CPAN authors don't understand versions 9/10 times.
  2. CPAN authors are prone to doing "special" things with versions that aren't even supported in perl, let alone the extensive ecosystem. ( They sometimes use usable versions internally by applying some monstrosity that probably involves "eval" to get a usable version at runtime, but the version stated on the package archive itself is garbage )
  3. Even people who could be considered influential in Perl screw up versioning enough to be a problem.

Subsequently, advice for downstream should be to run upstream versions through some normalization process with version.pm that decodes the version "as perl sees it", and then translates it to a downstream version with the same semantics.

This does mean you'll have to contend with "downstream versions are different from upstream versions", but that's just the reality one has to face.

Trying to get upstream to do everything right in ways that work for downstream is a fools errand, because usually, downstream care, and upstream simply don't.

perlpunk commented 4 years ago

You are right. Ideally vendors should use version->parse(...)->normal for the version. Adding a section about that is a good idea.

However, I'm also facing the reality that the existing modules in https://build.opensuse.org/project/show/devel:languages:perl took the CPAN version as it is. Changing all 3000 packages at once is close to impossible I would say.

Changing modules step by step is a hard task and we have to take into account that we not only need to fix the packages themselves, but also the ones that require them and would also need to have the new version format. For that we would have to keep a kind of database that saves information if the module/package is using the "new/correct" version or not.

In any case, that sounds like a lot of work. As far as I can see, in debian the version is also taken as it is, but if the module ever increased the number of digits in its version, then the number of digits is kept. I don't know how that is handled exactly. Needs more research.

kentfredric commented 4 years ago

Indeed, can confirm. I had to do this myself .... for Gentoo. But it is the sort of thing that you can slowly whittle away at and eventually get full coverage. My only residual problem is needing to cluebat the people who keep committing things with un-normalized versions, as even if they're not a problem now, history indicates they eventually will be.

kentfredric commented 4 years ago

For that we would have to keep a kind of database that saves information if the module/package is using the "new/correct" version or not.

Actually, as long as you always normalize to the 2-dots-or-more form, x.y.z, then you can, with reasonable safety, assume any version you see in that form is either already normalized, or using upstream's 2-dot form verbatim, which may be already compatible with your normalized form.

The only time this assumption doesn't hold is when somebody normalizes a version wrongly, but you're never going to fix that ;)