There's another twist here that we will need to account for: alpha releases.
The long standing convention of adding an underscore to a release to
indicate it's an alpha version should be respected. By default, when
we're choosing dependencies, we should be picking the latest NON-alpha
release by default. Using an alpha release at all should be a manual
override.
I think that's trivial to support. Basically, treat any NON-alpha release
as greater than any alpha release. For version objects, just use
->is_alpha, for non-version objects strings, just match against qr{_}.
If someone has nothing but alpha releases, we'll get the latest one. if
they have ANY non-alpha releases, we'll get the latest of those.
These changes should get cpan2efs to the point where it produces dependency
trees NEARLY identical to what you would get by using cpanp/cpanm/etc
against the same minicpan repo.
On Wed, Nov 2, 2011 at 11:04 AM, Phillip Moore <[email protected]>wrote:
> We have a major problem with both efs-perl and efs-deploy: we're using
> Sort::Versions (either the module, or our own versioncmp sub ripped from
> the module), which gets things WRONG for a lot of real world and important
> use cases.
>
> For example, Sort::Versions will consider DateTime-0.1401 to be a newer
> release than DateTime-0.70. The latter is the latest release. This is
> because it compares 1 to 1, and then 1401 to 70, and of course 1401 > 70.
> But, that's wrong....
>
> The best single document I've found on perl versions is this one:
>
> http://www.dagolden.com/index.php/369/version-numbers-should-be-boring
>
> Reading that again, I think we can use the following approach to fix this
> mistake: use version->parse to interpret version strings, and then compare
> the objects. We will need to eval both values being compared, and if we
> don't get version objects for both, then we will fall back on using the
> Sort::Version code to make the comparison.
>
> The only problem I can see is that in EFS 2 land, the oldest perl is
> 5.8.8, and version.pm was added to the core in 5.10. For efs-deploy,
> this is not an issue -- that code can simply depend on the CPAN module.
> For efs-perl, however, we can NOT depend on anything other than core
> modules, so we have to come up with a workaround.
>
> I think it's fair to say that no new EFS domains will be created going
> forward that support perl5.8. Therefore, I think we can cheat in EFS 2
> land. You already have perl5/version installed, so it might be reasonable
> to have EFS-Perl depend on the pre-installed version CPAN module to
> accomplish this. The question is HOW. For now, I'm going to punt on
> this, and when/if EFS 2 catches up with the leading edge of all this work
> I've done, we can work together to implement a solution.
>
> Look for a patch that implements this later today. Right now, I'm
> blocking on this....
>
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
