Notification System for Software Libraries

Because software libraries don't update themselves


What is VersionEye doing for me?

Version Notifications

Version screen d0024793d03c0e45244b7b1e0509caacee273f61027ba5d8a42d8029a6276fd3

VersionEye notifies you about outdated dependencies in your software projects. Nowadays software projects are based on many open source and self developed components. Checking manually for updates for these components is a very time consuming task and not fun at all! VersionEye notifies software developers via email about outdated dependencies in their projects. That way they can save a lot of time and focus on development.

Chart out dated ratio 1 5ef12dff274bed57e014cfdb34bf9fc18596d5219e18f7602270d62996662537

License Notifications

License screen 11c781f759837315df47dfcbbf0be304a212569cf8139ffc69d51278c5be2146

Nowadays software projects are based on up to 100 open source components or even more! Some of the components are published under a permissive and others under a copyleft license. If you develop closed source software you should avoid some licenses! VersionEye can check all your open source components against a license whitelist and notify you about violations! Depending on your software development process this checks can happen in real time and your software team can react immediately!

Chart license ratio 1 424e77d1b787e3a7664c6659227b3177bfb08b1a2446320c7bdb2194c4d27598

How does it work?


Login with your GitHub account and turn on the switch beside the project file you want to monitor. VersionEye will notify you about outdated dependencies via email.

Github integration b7032edc7fb06d0fa0f1e84c64d06cd38a4a1b1b54c9c33caf80df7f17ca5ffe => Versioneye project 38729dca2adf1bf78c3fec2f7a6698c1d9b8b563c1a9e3121887d2ec4b3e629d

VersionEye shows you all supported project files in all branches for all of your repositories. After parsing your project file you can immediately see which dependencies are outdated.


Login with your Bitbucket account and turn on the switch beside the project file you want to monitor. Our Bitbucket integration works exactly like the GitHub integration. The only difference is that we only show supported project files in the root of a branch. Project files in subdirectories are currently not displayed.


Let VersionEye know where your project file is located on the Internet and it will fetch it every day and notify you about outdated dependencies.


Just upload your project file and VersionEye will show you the outdated dependencies.


Run VersionEye Enterprise on your own server! Integrated with your private repositories and your continuous integration system! Read more here!

Package Managers

VersionEye currently supports these 10 package managers: Composer, Bundler, PIP, NPM, Bower, Leiningen, CocoaPods, Maven, SBT and Gradle.

JVM - Maven / Gradle / SBT / Lein / Ivy

For Java we support Maven of course! If your project has only one pom.xml file then it works fine with our GitHub/Bitbucket integration. If you project has multiple pom.xml files we recommend to use the VersionEye Maven Plugin. This plugin resolves the dependencies locally and creates/updates a project at VersionEye. This is especially useful for bigger projects with parent poms and reactor builds.

Gradle is also supported. VersionEye is watching for a *.gradle file in your project. In addition to that you can use the Gradle VersionEye Plugin from Simon Templer. It works similar to the Maven Plugin.

Apache Ivy support is part of our roadmap.

Because software libraries don't update themselves

They just become out-dated!

Because software libraries are not like iPhone apps

They are passive! They don't tell you that they are out-dated!

Because software developers are wasting time with ...

looking manually for updates. Save time and money by automating this process.

Because core committers of open source projects don't release new versions just for fun. Releasing a new version of an open source project is a lot of work. An artifact has to be build and published. Documentation needs to be updated and a releasenote has to be generated. If it's a major version a migration path has to be written. And in most cases the core comitters even don't get paid for this work. So they think twice before they release a new version. And every time they do so they have a very good reason for it. For example:

  • Bug Fixes
  • Security Fixes
  • New Features

This are all good reasons for you to update your dependencies to the newest version. If you don't update you are missing bug & security fixes and new features!

Check out the slides to Continuous Updating and don't forget to run your tests after the update. We don't recommend to use continuous updating without continuous testing, continuous integration and semantic versioning.

It's free to sign up!

Join today and track your dependencies.

Using one of these logins you automatically confirm that you have read the Conditions of Use and the Data Acquisition and agree to their validity.