On Fri, Oct 09, 2009 at 09:48:17AM -0400, David Golden wrote: > On Fri, Oct 9, 2009 at 7:43 AM, David Golden <xda...@gmail.com> wrote: > > 04. Formalize allowed version number formats > > > > Proposal: > > > > Formalize the spec for version numbers as "decimal or normalized > > dotted-integer (leading "v" and at least 3 components). (Dagolden) > > > > Comments: > > > > * It's not clear whether/how to include alpha versions (with underscores) > > in the spec as they generally cannot be resolved by the toolchain > > (Dagolden) > > I have mixed feelings about this still. I'd like to rely on > version.pm's normalization so we don't re-implement it, but I really > don't like it's alpha comparison logic. I think alpha's should > compare "numerically" without regard for alpha status, which is really > just distribution-level meta information about whether it should be > indexed or not. > > Disallowing underscores in META would be a way to enforce this, but > then comparing version in META and version in $VERSION is harder.
Agreed that this needs to be made clear, but I think disallowing underscores may cause more problems than it's worth. > > * Version comparison for "greater than" must be both possible and fully > > described in all possible combinations, as things like Module::Install > > need to handle duplicate dependency assertions. For example, part of the > > M:I internals silently assert "requires File::ShareDir 1.23". If the user > > then manually asserts "requires File::ShareDir v1.24.1" M:I needs to be > > able to determine which to keep and which to discard. > > (AdamKennedy) > > I agree in principle, but I disagree on "all possible combinations". > We shouldn't try to specify heuristics to deal with the ways people > screw up version numbering. (e.g. 1.23 => v1.230.0 which is greater > than v1.24.1). As long as we specify dotted-tuple-with-leading-v or > decimal as allowed formats, we know how to compare those > (notwithstanding 64-bit precision decimal conversion bugs). Dotted > tuple without leading v we can assume to be a badly formatted tuple > and we can be liberal. (*must* emit strict to spec, *may*/*should* > interpret 1.2.3 as v1.2.3) We should make it clear what version formats are acceptable, and in the event of any possible ambiguity, what will be assumed. Cheers, Barbie. -- Birmingham Perl Mongers <http://birmingham.pm.org> Memoirs Of A Roadie <http://barbie.missbarbell.co.uk> CPAN Testers Blog <http://blog.cpantesters.org> YAPC Conference Surveys <http://yapc-surveys.org>
