[Bug 29880] package-version - limits

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29880

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
Yes, it's definitely a ridiculous version number, I believe I added it to test
our version parser, which parses it fine, but cannot use it in version
comparison as that uses native 64 bit integers.

I wasn't aware of the 16 digit limitation, I don't see that in the spec.

I don't think we should limit it to arbitrary ranges, though. It is not
inconceivable that versions will match build versions of a containing product,
and there are several out there (at least in the .NET world) with four segments
and at least one segment (usually the build no) that have five digits.

However, I think it makes sense to limit it to, say, the range xs:unsignedInt. 

Also, I don't think a processor should reject anything if the version appears
on the principal package. Instead, I propose that it may fail to find a
matching package if such outerworldly package numbers are used in version
ranges on xsl:use-package.

Same is true for the number of version components. I don't think we ought to
limit that. We made a conscious decision at the time to make the version number
as unrestrictive as possible. Though if we do decide in favor of limitation, I
think four is a better number of components (because a large body of existing
software, namely everything on Windows, uses four-component version numbers).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 29 September 2016 13:44:26 UTC