Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify version description given Lyon compromise #109

Open
haarg opened this issue May 10, 2016 · 2 comments
Open

Clarify version description given Lyon compromise #109

haarg opened this issue May 10, 2016 · 2 comments
Labels

Comments

@haarg
Copy link
Member

haarg commented May 10, 2016

One part of the decision in the Lyon compromise was that underscores in dotted-integer versions should be ignored rather than treated as a tuple separator. This brings them in line with numeric versions, where the underscores are similarly ignored. The text in CPAN::Meta::Spec states

This are equivalent in format to Perl "v-strings", with some additional restrictions on form. They must be given in "normal" form, which has a leading "v" character and at least three integer components. To retain a one-to-one mapping with decimal versions, all components after the first should be restricted to the range 0 to 999. The final component may be separated by an underscore character instead of a period.

This is still basically compatible with the Lyon compromise. It does imply meaning to the underscore that no longer applies, however that is mostly not a large issue because the spec doesn't say anything about how these versions should be interpreted, instead pushing that off on the version module.

However, if we were to update the text to be in line with Lyon, it would become more restrictive. Specifically, v1.2_3 is valid under the current spec. But if _ is no longer a component separator, it becomes illegal due to the requirement of three components.

@kentfredric
Copy link
Contributor

I think its only logical to treat it identically how we currently treat v1.23.

If v1.23 is illegal, then v1.2_3 is also.

Though this is likely a backwards incompatible change to Spec validation if we tried to enforce this, which may require a minor version increment in the Spec definition before we start yelling at this.

@haarg
Copy link
Member Author

haarg commented May 21, 2016

What I'd prefer is some adjustment to the text, given Lyon, but without changing the actual requirements.

@xdg xdg added the spec label Jun 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants