Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian Version strings like 7.0.28-1 are not supported #10

Open
theseer opened this issue Apr 6, 2018 · 4 comments
Open

Debian Version strings like 7.0.28-1 are not supported #10

theseer opened this issue Apr 6, 2018 · 4 comments
Assignees

Comments

@theseer
Copy link
Member

theseer commented Apr 6, 2018

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.

@eclipxe13
Copy link

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.

@eclipxe13
Copy link

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 in Version 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.

@theseer
Copy link
Member Author

theseer commented May 15, 2018

Thank you for considering to implement it.
I fully agree with your assessment for requirements.

Since everything depends on Version and not an interface, then PhpVersion should be a subclass of Version?

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 (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.

That should probably be fixed as well but is likely a different issue.

@sebastianheuer
Copy link
Member

Various types of labels are now supported - see #11 for details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants