-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Clarify kind of version number #62
Comments
I am strongly for permitting under version the semver - e.g. This is used in https://OpenMapTiles.org/ vector tiles already. The reason: the version can be then used for compatibility of style to a data schema version of tiles in a semantic version approach. If a GL style is compatible with a major version - it is guaranteed to not break the look&feel of the map. |
The spec is pretty clear to me - it needs to be a number, which semver is not. If this change were desirable, would it have to go into 1.4 or 2.0? |
Thanks for jumping in @pnorman It sounds to me that the value "3.11" is not breaking the spec, as it is a number - so technically the stored value in OpenMapTiles releases is correct. |
The spec doesn't define what a number is, but the example bounds which is numbers indicates "180.0" is a number. But keep in mind 3.9 > 3.11 > 3.0 if you want to define your system's version as a floating point number. |
spec 1.3 tells:
When seeing 'number' here, I thought an natural number 1, 2, 3, ... because usually, revision number is natural number.
Am I right? Or, does the 'number' mean a real number?
By the way, if you meant a real number, it could be confusing because the type of field is
TEXT
.When one see 1.3 as a string, he or she may consider it as a semver style version "1.3.0" not a floating point number 1.3 (that is, 13/10).
This could result into wrong comparison. For instance, for real number, 1.3 > 1.15, but for semver, "1.15" > "1.3".
The text was updated successfully, but these errors were encountered: