Dependencies management: versioning

It’s a really complicated topic. Almost everyone has own opinion on it. I’ll try to describe you several patterns with pros and cons for each.

It doesn’t matter if it’s a python dependency in requirements.txt or a javascript one in package-lock.json file.

What could go wrong? First of all, there are several approaches how dependency could be described:

Case 1: without version

It’s a great approach for development on early stages. You always use the latest version and you’ll be notified soon if your application stopped to work. On the other hand, it’s a nightmare for production deployment. Everything could stop work at any moment after any operating system update.

Case 2: with strong version pinning

It’s the most stable approach. Once you start your application and freeze dependencies, everything will work without any issue. A lot of deployment engineers prefer this way. It’s good for production but it does not provide a good development experience. After each version update in your requirements file, you need to test your application with a new dependency version before starting to use it

Case 3: min/max range

It’s one of the easiest ways to handle dependencies. Once you added new dependency into the project, you specify the version as a minimum one. If something fails with a new version, you just add a maximum cap for your dependency version and use it until application will support it.

Case 4: min/max range with some exception

It’s almost the same as a previous one but adds an ability to skip some version. E.g. you can work with v.1.0-2.5, but v.2.4.3 introduces some issue which you want to avoid. IMO, it’s the most powerful and convenient way to deal with dependencies in a project. It’s flexible enough both for developers and deployment engineers.

Tags

.net .net-framework .net-framework-3.5 agile ajax ajax-control-toolkit ampq ansible apache asp.net asp.net-mvc automation axum babel bash benchmark blog blog-engine bootstrap buildout c# cache centos chrome ci cinder ckan cli cloud code-review codeplex community config debugger deface dependencies development-environment devices devstack devtime disks django dlr dns docker dockerimage dos easy_install elmah encoding environment-variables error event events everything-as-a-code exception exceptions fabrik firefox flask foreach forms fstab gae gcc gerrit git github go google google-app-engine grep hack hacked hardware headless horizon hound html hugo iaas ienumerable iis internet iptables iron-python ironic iscsi java-script javascript jenkins jquery js jsx kharkivpy kiss kombu kvm kyiv lettuce libvirt linux lio loci logging loopback losetup lvm mac-os macos mercurial microsoft microsoft-sync-framework mobile mono ms-office msbuild networking news nginx npm npx offtopic oop open-source open-xml opensource openstack openvswitch os packages paraller-development patterns-practices performance php pika pip plugins pnp podcast popup postgresql profiler project protocols proxy pycamp pycharm pycon pykyiv pylint pypi python python-3 qcow quantum qumy rabbitmq rar react reactjs refactoring rfc rhel search-engine security selenium server shell silverlight socket software-engineering source-control sourcegear-vault sources sql sql-server sql-server-express sqlalchemy ssh static-site sublimetext svg tests tgt tipfy tornado typescript uapycon ui uneta unit-tests upgrades usability vim virtualenv visual-studio vitrage vm vue.js vuejs web-development web-server web-service web_root webpack webroot windows windows-live word-press x32 x64 xcode xml xss xvfb интернет-магазин книги


Archives

2019 (73)
2018 (2)
2017 (3)
2016 (2)
2015 (3)
2014 (5)
2013 (17)
2012 (22)
2011 (35)
2010 (25)
2009 (35)
2008 (32)
2007 (2)