Kent Fredric

> future language ecosystems should hopefully avoid adding too many new variants for version numbering and ordering Unfortunately, only Perl is really adequate to compare perl versions. Presently you've got...

> Could this be per-ecosystem rather than per-project? "Backends" are essentially "Ecosystems" at present, just its in terms of the mechanism the code is accessed, eg, if its sourced from...

> Sorting then becomes a thing in the UI, but getting it wrong doesn't mean we fail to announce a new version. That becomes a question how it maps to...

> There are plenty of opportunities here to cater to individual projects - optionally ignoring pre-releases if the version scheme supports it, ignoring tags/releases that aren't parsable by the version...

This is just an example I stumbled over today of it handling versions wrong for CPAN: https://release-monitoring.org/project/7606/ https://metacpan.org/release/CBOR-XS Monitor thinks `1.41` is the latest ( 2016-02-25 ), when the latest...

This would also reduce the frequency of being annoyed by bug #913

> Out of curiosity, may I ask why you need to do `--no-default-features` when running tests on your side? Firstly, dependents can specify this, so it makes sense to test...

I've proposed some metadata extensions https://github.com/Perl-Toolchain-Gang/CPAN-Meta/issues/82 which would (among other things) allow CPAN authors to easily and authoritatively state "this dist requires a compiler", so that if such a field...

The "real code" is here: https://metacpan.org/source/KENTNL/Gentoo-Util-VirtualDepend-0.003017/maint/update-module-to-gentoo.pl But I can trivially reproduce the failure: ``` perl #!perl use strict; use warnings; use MetaCPAN::Client; my $client = MetaCPAN::Client->new( version => 'v1' );...

Its strange, because I've been running this code now for over a year, and this is the first time its had "undef" turn up instead of the version. Its possible...