Eric Wilhelm wrote:
>>>> To this end, the META.yml version should be normalized to a simple
>>>> decimal.  use version->numify. 
> 
> What is gained by doing this?

You can sort versions as simple decimal numbers without any special logic
(except the X.Y_Z thing which is orthogonal, yet still odious, and has a
different solution).  numify turns X.Y.Z into X.00Y00Z.


> And how does it fit what David said about the archive name?

While it would be nice if the version in the META.yml was formatted the same
as on the archive, I have no problem they're being different.  It's more
important that META.yml remains easy to machine parse and understand.
META.yml is a spec.  Archive names are just convention.


> And what does 'alpha' or 'do not index' have to do with it?

Just illustrating that the idea that parsing Perl versions is pretty damn
complicated and we can't expect every tool to replicate that logic.  It's
otherwise orthogonal.


> I think the 4 things version numbers are needed for are basically:
> 
>   1.  Compare versions (with the perl runtime, or as data|dependencies).
>   2.  Construct an archive name.
>   3.  Navigate the PAUSE indexer (parse an archive name?)
>   4.  Deconstruct/compare/manipulate dists (search/meta tools)
> 
> So, maybe numify works, but I suspect that it causes more problems than 
> it solves until all 4 of these uses have accounted for vX.Y.Z versions 
> and some sort of 'alpha' marker.

Since those things all already have to know how to compare vX.Y.Z with X.Y
mixing numified versioned objects (X.00Y00Z) with stringified version objects
(vX.Y.Z) shouldn't cause an issue.


> Maybe you can forget about constructing an archive name from META.yml 
> and even put the alpha flag in there.  Some meta tools do need to 
> reconstruct an archive name, but they will have to map $dir->list 
> through a parse+numify to get there.

Numified version objects round trip.  If anything is going to give here, it's
the archive name.


-- 
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
        -- tchrist in <31832.969261...@chthon>

Reply via email to