Labeling the different update processes

Updatability of software relies on many different mechanisms and comes in many different forms each holding their own limitations. Lately, we have gotten the question a lot around how we could update components of Compony. This blogpost is intended to explain some different concepts of updatability in the wild. Having these different concepts under our belts will be needed to take this a step further as a community.

This blogpost is the first in a mini-series where we explore the different facets of updatability:

  1. The different update processes currently in existence. (This blogpost)
  2. The side-effects of each of these update processes
  3. Inspecting Composer and NPM’s updatability.
  4. Updating Compony components.

The evergreen process #

The evergreen concept can be best explained by using the example of browsers. There is a good chance you will be running the latest or second-to-latest stable version of Chrome or Firefox. That’s because for many years already, these browsers have been built as evergreen browsers. The browser will automatically update itself without you having a say in the matter. 

This means that evergreen browsers can evolve as fast as they choose themselves, without having to wait for all of their users to update to the latest version. 

This is indirectly the reason developers had to support Internet Explorer (IE) versions for such a long time even after the Edge browser got released. And that is because IE11 is the very first version of IE that embraced the evergreen concept.

The "suggestive update" process #

Before evergreen browsers, browsers would show us a notification saying “there is a new version available”. 

Alongside this notification, you would get 2 suggestions:

  • Update now
  • Skip this version / maybe later

This suggestive way can have multiple results, depending who receives this notification. Offering this option is gives people the choice of sticking to the version they currently have or choosing to update at a later time. While this is often considered a good practise. It’s also an excellent time to show the users of your software what is new or improved. 

It’s possible for these notifications to offer a checkbox along the line of: “don’t ask me again”. And depending on what choice you made after checking this checkbox, it’s likely you chose to make a suggestive update process become evergreen for your system. 

Schrodinger's update process #

Some software only updates if you manually check if there are updates to be done. For example: you can disable automatic updates for Firefox, which gives you a bit of control, and let’s you check what changed for example. 

Having these automatic updates disabled, puts me in a Schrodinger’s situation. Both situations are true at the same time: there are both updates available and I am on the latest version.

The migration process #

Sometimes, software gets rewritten in such a fundamental way, that clicking a button is not enough, and you have to do something manually. 

When this is required in a process, let’s call that process a migration. The reason that a button is not enough, is either because you have choices to make, or that the part of the software that gets updated, can be in a state that is unpredictable.

Published 09 December 2019
Updated 10 January 2020