MAJOR.MINOR.PATCH 1.MAJOR version when you make incompatible API changes 2.MINOR version when you add functionality in a backwards-compatible manner 3.PATCH version when you make backwards-compatible bug fixes.
2.0.0 Major 2.1.0 Minor 2.1.1 Patch 2.1.2 Patch 3.0.0 Major
Always follow the MIGRATION PATH
Many small steps are better than one big step You can do SMALL MIGRATIONS on the fly. BIG MIGRATIONS are risky and expensive. If you miss versions, you miss migration paths, too. And that leads to TROUBLE!
Don’t miss migration paths! migrate migrate migrate 1 2 3 4 on the fly on the fly on the fly big migration … expensive!
Always run your TESTS against new versions
Another reason for being current
Do you really believe those young talents wanna work with COBOL? Or other OLD SHIT?
Tracking versions is a pain!
SOFTWARE LIBRARIES are NOT like iPhone Apps!
100 libraries per project in avg. After 2 weeks the first libraries are OUT-DATED!
Developers are missing critical BUG FIXES and important UPDATES!
Manually checking for updates is no fun! It cost TIME & MONEY! NOBODY WANTS TO DO IT!
So, how do you wanna solve this PROBLEM
You have to AUTOMATE
You need a TOOL for that!
GemNotifier Gemnasium VersionEye Ruby, Node.JS, Languages Ruby Python 22 Languages GitHub no yes yes Bitbucket no no yes File upload no no yes URL parsing no no yes Changelogs no yes in progress Security no yes in progress Licenses no no yes API no no yes
www.VersionEye.com Keeps an eye on more than 550K open source libraries! Supports 22 Languages and 10 Package Managers!