Debian Version strings like 7.0.28-1 are not supported
theseer opened this issue · 4 comments
While it is arguable whether or not the string 7.0.28-1
is semver compliant, we obviously have to face reality and deal with it.
Maybe @oerdnj has the acknowledge of why php has suffixes in debian (and derivates), don't know if he wants to take a look here.
As far I understand from PR phar-io/phive#142 a new PhpVersion
class would be needed in this project.
What are the requirements to this class?
- It should be able to create the object from
PHP_VERSION
as input as inVersion
constructor - It should honor the "standard"
major.minor.release[extra]
- It should compare using the spec defined in
[version_compare](http://php.net/manual/en/function.version-compare.php)
- Anything else?
I was thinking about coding this, but I have some design doubts that need your guidance.
How would you like to implement it?
Since everything depends on Version
and not an interface, then PhpVersion
should be a subclass of Version
?
Why is important to have the extra
(or PreReleaseSuffix
in SemVer) besides informative?? the library is not using this data to compare to versions, so version 1.2.3-rc4
is actually greater than or equal to 1.2.3-rc5
.
Thank you for considering to implement it.
I fully agree with your assessment for requirements.
Since everything depends on
Version
and not an interface, thenPhpVersion
should be a subclass ofVersion
?
Good point. And no, Version
should probably be turned into an interface and the current Version
class should be renamed - for instance into SemanticVersion
?
This will probably lead to a major version increase as this is not backwards compatible.
Why is important to have the
extra
(orPreReleaseSuffix
in SemVer) besides informative?? the library is not using this data to compare to versions, so version1.2.3-rc4
is actually greater than or equal to1.2.3-rc5
.
That should probably be fixed as well but is likely a different issue.
Various types of labels are now supported - see #11 for details.