Author: versioneye

VersionEye now has dependency badges for Java, PHP, Ruby and Node.JS.  You can find them on every package page.  They look like this:

When you click on one of these badges, a pop-up will appear with some sample code showing you how to integrate the badge into your page.  These are some examples for the most commonly used meta languages such Markdown, Textile, RDoc and HTML.

We have badges for every Java, PHP, Ruby and Node.JS open-source library you can find using the public search on VersionEye.  In addition, we offer these badge for your private projects at VersionEye.  And as soon as you turn your VersionEye project public, you can embed the badge into other pages as well.

We consider a project to be stable if all of its dependencies are using the latest stable version.

We are looking forward to seeing these badges on many GitHub pages 🙂

http://www.versioneye.com
We keep you informed

We just pushed a new version online. The Dependencies are now displayed in a table view. This is how it looks for Hibernate-Core.

You can see immediately which dependencies are outdated.

We did the same for private projects. Here is an example how it looks now.

This view is more compressed and you can see more details without scrolling.

VersionEye: We’ll keep you up to date!
https://www.versioneye.com

We have a link section in the settings where you can put in your social ids to other Dev. Platforms, such as GitHub & Stackoverflow. We changed this section. It works now with absolute links.

In that way there is less confusion.

The PHP package manager Composer has a very cool feature called minimum stability. It defines the minimum stability of wildcard versions.

Let’s say you define the following in your composer.json file:

“symfony/finder” : “2.2.*”

By default, the minimum stability is “stable”. That means the package manager will look for the newest version in the “2.2.” branch which is stable. If you are looking for the newest dev version you can redefine the minimum stability for this package to:

“symfony/finder” : “2.2.*@dev”

In that case you would get the newest development and unstable version of the “2.2.” branch. Possible stability tags are “@dev”, “@RC”, “@stable”, “@beta” and “@alpha”.

VersionEye now understands the minimum stability tags Composer uses and can handle them. But it is an early implementation. Your feedback is highly welcome!

The VersionEye API enables you to create a project using the API. All you need to do is use POST to send your project file to the “/v1/projects.json” endpoint. VersionEye then creates a new project for it and returns a JSON with the used libraries and any outdated information.

There is already an add-on for the Symfony Developer Toolbar:

https://github.com/mattsches/VersionEyeBundle

And one for the Zend Dev. toolbar:

https://github.com/Ocramius/VersionEyeModule

These modules send your composer.json file to the VersionEye server.  Unfortunately, the first version created a new project at VersionEye each time there was a post. This is not the desired behavior. We added a new endpoint to the API which enables API developers to update existing projects.

The process now looks like this. First, you upload the composer.json file via POST to this resource: “/v1/projects.json“. In the response, VersionEye returns a “project_key” for the project. Next, you send the composer.json file via POST to this new resource: “/v1/projects/{project_key}.json“.

The new endpoint, “/v1/projects/{project_key}.json”, does not create a new project. It only updates an existing project. Please use it in the future to update an existing project.

We finished the RSS feature for VersionEye. You can now subscribe to your libraries via RSS. On your profile page, there will now be an RSS icon next to your favorite packages.

Simply click on the icon and you will always receive the latest version notifications via your favorite RSS reader. I use RSS Toaster.

And the cool thing is that you are now also able to get the notifications on your smart phone.

Or on your favorite tablet.

Please let us know if you have questions.

The new VersionEye API enables you to fetch a list of all licenses of your software project.  VersionEye now supports 7 different package managers. In my example, I use a Ruby Gemfile to show how easy it is to get the license list.

First of all, you need to sign up at VersionEye to get your API_KEY.  The key is free and the whole process takes less than 30 seconds.  As soon as you have your API_KEY, you can take full advantage of the VersionEye API.

The “/api/v1/projects.json” resource supports file uploads via the API.

Send your Gemfile via POST to this resource and you will receive a JSON object with all the dependencies in the file.

The JSON response contains a “project_key”.  This project key is unique for each user.  You can use it to fetch all licenses of the project.  All you need to do is send a GET request to “/api/v1/projects/PROJECT_KEY/licenses.json?api_key=API_KEY” and you will receive the license list as JSON.

That’s it.  You only need two requests to get the license list.

Please let me know what you think of this feature.

VersionEye tracks open source software libraries.  We are not interested in source code but in releases that are already finished.  Or in other words: In artifects that are „completed“ and which you can use in your projects.  The graph below shows the number of projects tracked per language.

These figures are compiled from more than 50 different repository servers in the Internet, including repository servers such as RubyGems.org, pypi.python.org, packagist.org and more than 40 Maven repository servers.  SCM tools such as GitHub or BitBucket have not been taken into consideration.

The graph only shows software library projects.  It does not include desktop tools written in Java and hosted on SourceForge.

In the next graph, you can see the growth of the repositories over time.

VersionEye only started crawling repositories in April.  That is why we cannot go back any further in time.  However, the last months are already enough to show the speed in which the repositories grow.  If RubyGems keeps on growing in that pace, it will soon be no. 1.

On VersionEye‘s website, you will always find the latest graphs (updated on a daily basis): https://www.versioneye.com/statistics

We keep you informed.