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_VERSIONas input as inVersionconstructor - 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
Versionand not an interface, thenPhpVersionshould 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(orPreReleaseSuffixin SemVer) besides informative?? the library is not using this data to compare to versions, so version1.2.3-rc4is 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.