I went to the Technology Radar event from ThoughtWorks in Hamburg, a couple days ago. they presented the latest trends from the last year and explained their decision making decision. It was a very interesting event.
The MeetUp will happen at CO.UP in Kreuzberg. Which is a pretty cool coworking space.
Locafox, a young StartUp from Berlin, will sponsor pizza & beer. They are currently hiring in all areas. Check out their job listings here: http://locafox.de/jobs. And many thanks for the pizza. We really appreciate that.
I have to work with a lot (9) of different package managers at my daily work at VersionEye. Part of our mission is it to make manual updating of dependencies extinct, because it’s a manual and time consuming task which nobody enjoys. That’s why we are building a notification system for open source software libraries to make Continuous Updating easy and fun. And since we support several programming languages – 8 at this point! – I get to write crawlers and parsers for all of them. To give you a better overview over the strengths and weaknesses of these package managers, I picked the most popular one for each language and will compare them. The contenders are:
- RubyGems / Bundler (Ruby)
- PIP / PyPI (Python)
- Packagist / Composer (PHP)
- NPM (Node.JS)
- Bower (JS, CSS, HTML)
- CocoaPods (Objective-C)
- Maven (Java)
- Lein (Clojure)
Here are the results of my comparison.
This is the pattern it describes:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards-compatible manner
PATCH version when you make backwards-compatible bug fixes
The cool thing here is that on the version number itself you can already see how big the changes are in the new release. A typical semantic version number is this:
Let’s say I am using version “3.2.0″ in my project. Now I can immediately see that the new version of the package “only” contains a patch. That means for me that I can update without worrying. On the other side if this version comes out:
And I am using version “3.2.1″ of the package in my project, I can now immediately see that this update will very likely break my build! In this case I have to look into the change logs and follow the migration paths.
Semantic versioning even addresses alpha and beta versions. If you are working on version “4.0.0″ but it’s not quiet ready but you wanna release anyway something, you can name it like this:
That means that is version “4.0.0″ alpha. And this here would be the beta version:
Another convention is “RC”, that means “Release Candidate”. You can use it like this:
The complete order over all of them is like this, the highest and newest version is on the top.
4.0.0 4.0.0-RC2 4.0.0-RC1 4.0.0-b 4.0.0-a
That basically means 4.0.0 > 4.0.0-RC2 > 4.0.0-RC1 > 4.0.0-b > 4.0.0-a.
I’m the author of naturalsorter. That is an open source library to sort semantic version numbers in the correct way.
You can follow the Objective-C packages you are using in your projects for your iPhone dev work and as soon the next version is released you will get notified via email.
If you are using CocoaPods as package manager you can directly upload your Podfile to VersionEye and you will see the out-dated dependencies. This here is a simple Podfile.
platform :ios pod 'SSToolkit' pod 'AFNetworking', '>= 0.5.1' pod 'CocoaLumberjack' pod 'Objection', :head # 'bleeding edge' generate_bridge_support!
It defines 4 packages for the project. If your project is on GitHub, VersionEye can directly monitor your Podfile in your GitHub repository and notify you as soon there are updates available for your project.
The CocoaPods integration is a very new feature. We rely on your feedback. Please let me know if you find something odd or your have further feature requests.
Originally posted on Continuous Updating:
If you want to find out which version of a software library for your programming language of choice is the latest, you had to go the libraries’ website or the repository. Finding the website, the latest version and getting reminded on important bugfixes for the libraries you use can cost a lot of time.
VersionEye is a website that tracks software libraries in 8 different programming languages and 7 package managers. Eg. if you are a Ruby developer you might be interested in the latest Rails, Sinatra or Capybara version. As a Java developer the latest versions of Spring, Guice or Hibernate might be of interest for you.
If you regularly search for software libraries you may want to have a search engine directly in your browser. VersionEye now supports OpenSearch so you can add VersionEye as a search engine to your browser and quickly find out what…
View original 194 more words