PHP Runtime Compatability

Now VersionEye shows which PHP package is compatible to which PHP runtime.

PHP has different runtimes, just like Ruby and Java. There are different versions of the PHP interpreter, there the newest is currently the 7.X branch, which brings massive performance improvements. But there is also the HHVM runtime, developed by Facebook. HHVM is a virtual machine for PHP and Hack, which is using a JIT compilation approach. Not all PHP libraries are running on HHVM or on PHP 7.

The PHP-Eye project from Julius Beckmann is collecting travis-ci configurations from GitHub and the corresponding test results to detect if an PHP artefact is compatible to a specific runtime or not. This kind of information is not available for all PHP libraries. But for many of them. For the good ones who are doing continuous testing and continuous integration. For this projects a runtime badge can be generated. VersionEye displays for each PHP artefact 2 runtime badges at the top of the page.

VersionEye-PHP-Runtime

That way it’s easy to see on which runtime the selected artefact was tested an on which not. The runtime badges link directly to a page at PHP-Eye where the full compatibility matrix for the PHP package is displayed.

Screen Shot 2016-03-03 at 09.46.50

VersionEye is using this information for the notification emails as well. Now in the notification emails the tested runtimes are listed as well. Like in this example:

Screen Shot 2016-03-03 at 19.58.57

We hope this information is valuable for you and helps you to build better software. Your feedback is always appreciated ūüôā

Composer Stability Flags

Composer has a cool feature, called stability flags. That allows you to specify the stability of a dependency.

minimum-stability

Assume there is no stable version of silex/silex. Then this entry

{
    "require": {
        "silex/silex": "1.0.*@dev"
    }
}

would install 1.0.x-dev, the dev version of the 1.0 branch.

I always interpreted “@dev” as “take the newest, even if it is unstable”. But currently I had this dependency in a composer.json:

"doctrine/migrations": "1.0.*@dev"

And Composer¬†resolved that to “1.0.0-alpha3”. I do not really understand why. There is a stable version 1.0.0 and if “@dev” means “take the newest unstable version” then that would be 1.0.0-rc1.

If somebody can explain why “@dev” resolves to “1.0.0-alpha3” in this case please leave a comment here.

Support for composer-asset-plugin

Composer is the dependency manager for PHP. Dependencies are defined in a composer.json file, very similar to the package.json file from NPM. Composer is awesome because it’s solving the problem of installing 3rd party libraries.

logo-composer-transparent

But it is only handling PHP packages from packagist.org. Specially in a web environment many times you need some CSS and JavaScript packages as well. For that use case there is the composer-asset-plugin now. With that plugin you can reference NPM packages and bower packages in your composer.json. That way you have ALL your dependencies in 1 single file. If installed correctly you can reference an NPM packages just like this:

{
    "require": {
        "npm-asset/bootstrap": "dev-master"
    }
}

And a bower package like this:

{
    "require": {
        "bower-asset/bootstrap": "dev-master"
    }
}

Up to now this dependencies have been marked as UNKNOWN from VersionEye, because VersionEye was looking for a PHP package with the name “bower-asset/bootstrap”. But now the composer-asset-plugin is supported and these dependencies are handled correctly.

Please try it out your self and give feedback.

PHP Security Vulnerabilities

Now VersionEye has notifications for security vulnerabilities! This new feature currently only works for PHP. Right now we have 118 security vulnerabilities in our database which affects some of the most used PHP frameworks and libraries. The security vulnerabilities are fetched from the SensioLabs security database. VersionEye is displaying the security vulnerabilities directly on the VersionEye detail pages. Here is an example.

Screen Shot 2015-05-07 at 14.08.05

VersionEye is displaying at least 1 link to an article where the security vulnerability is documented in great detail. Beside that the affected versions are displayed as well.

But that’s not all. If VersionEye is monitoring your PHP project directly on GitHub/Bitbucket or Stash, you will see a “Security” tab in your project view. Here is an example.

Screen Shot 2015-05-13 at 15.28.22

In the “Security” tab we display known¬†vulnerabilities for your project. If there are any security¬†vulnerabilities for your project the dependency badge turns red to “update!”.

This feature is strongly based on locked versions. If VersionEye has access to your composer.lock file it knows exactly which version you are using in production and it can assign security¬†vulnerabilities 100% accurate. If VersionEye has only access to your composer.json file, but not to your composer.lock file it doesn’t know which versions exactly you are using in production. In that case VersionEye¬†assumes that all version expressions are resolved to the newest version. But because we don’t know it for sure, it doesn’t affect the dependency badge. For composer.json files we display that hint in the security tab.

Screen Shot 2015-05-13 at 15.35.58

If you want to take full advantage of this feature you should commit your composer.lock file to your git repository and give VersionEye access to it. That is anyway best practice.

This feature is very new and we heavily rely on your feedback. Please try it out and let us know if you find anything odd.

Better support for Zendframework

VersionEye is tracking over 57K PHP projects every day, from 5 different repositories! Yesterday the Zendframework repository was added.

zend-framework-2-logoThis repository gets crawled once an hour! The same is true for Magento, Firegenot and Tiki! Packagist gets crawled once a day.

If you have a public Satis repository you would like to track at VersionEye, simply shoot us the link on Twitter ūüėČ

Update for PHP Branches

VersionEye is crawling Packagist once a day for new packages and new versions. Packagist is treating new branches as versions. Some PHP projects, like cakephp, are very active and they produce many new branches.

Cake-logo

Up to now VersionEye send out notifications for each of this new branches. Some of our users complaint already that they don’t want to get notified about each branch. That’s why we refactored the crawler for packagist. Now we check for each new “version” if there is a corresponding tag on GitHub. If we can’t find a corresponding tag on GitHub we skip that version, because it must be a branch.

This change does not effect the already crawled data.