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.


.net .net-framework .net-framework-3.5 agile ajax ajax-control-toolkit ampq ansible apache 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 k8s kharkivpy kiss kombu kubernetes 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 todo 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 интернет-магазин книги

Recent posts

Go 1.18: new features

Всё будет Kubernetes

2022 Relaunch

Everyday Blogging

I don't want this CI


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