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. > * 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) -- David
