I like vers and we support it. However, I think there is one change that vers should do to make it easier to implement, evaluate (also for humans) and write:
Please remove the option to have "non-canonical / unnormalized" vers. Actually, it SHALL be prohibited.
The "non-canonical / unnormalized" vers has the following disadvantages:
-
Complexity in Parsing: Supporting multiple forms increases the complexity of tools and libraries. Developers must implement parsing logic for each variant, leading to potential bugs and maintenance challenges.
-
Increased Errors: The likelihood of errors rises when multiple forms are allowed. Developers might mistakenly input an allowed (as non-canonical) but unintended version constraint, causing deployment failures or dependency conflicts.
-
Documentation Overhead: Maintaining a description for converting into the canonical form requires additional effort. The vers spec team must ensure that every part of the spec works for both forms, increasing the risk of overlooking updates.
-
Confusion Among Team Members: When teams use different forms (canonical vs not), it can create confusion and miscommunication. This hampers collaboration and makes it harder for new team members to understand existing documentation using vers.
-
Test space: The space that must be covered with test cases gets pretty fast very big as the "non-canonical / unnormalized" vers offers multiple ways that lead to the same canonical vers.
-
Risk of under-specification: When trying to map an infinite set (but still countable ;-)) of "non-canonical / unnormalized" vers into the canonical form, there is a high risk that the mapping rules are incomplete or misinterpreted. For example:
Spaces are not significant and removed in a canonical form.
Does that include just "space" as in 0x20 or any white space? If the latter: Which definition of white space applies?
I like vers and we support it. However, I think there is one change that vers should do to make it easier to implement, evaluate (also for humans) and write:
Please remove the option to have "non-canonical / unnormalized" vers. Actually, it SHALL be prohibited.
The "non-canonical / unnormalized" vers has the following disadvantages:
Complexity in Parsing: Supporting multiple forms increases the complexity of tools and libraries. Developers must implement parsing logic for each variant, leading to potential bugs and maintenance challenges.
Increased Errors: The likelihood of errors rises when multiple forms are allowed. Developers might mistakenly input an allowed (as non-canonical) but unintended version constraint, causing deployment failures or dependency conflicts.
Documentation Overhead: Maintaining a description for converting into the canonical form requires additional effort. The vers spec team must ensure that every part of the spec works for both forms, increasing the risk of overlooking updates.
Confusion Among Team Members: When teams use different forms (canonical vs not), it can create confusion and miscommunication. This hampers collaboration and makes it harder for new team members to understand existing documentation using vers.
Test space: The space that must be covered with test cases gets pretty fast very big as the "non-canonical / unnormalized" vers offers multiple ways that lead to the same canonical vers.
Risk of under-specification: When trying to map an infinite set (but still countable ;-)) of "non-canonical / unnormalized" vers into the canonical form, there is a high risk that the mapping rules are incomplete or misinterpreted. For example:
Does that include just "space" as in
0x20or any white space? If the latter: Which definition of white space applies?