How do software updates work?

572 views
0

I’m just wondering what happens under the hood, so to speak, when let’s say, an application is updated. Is it just code rewriting/addition…?

In: Technology

What’s delivered in patches are compiled binary files, media files and text configuration files. The binaries represent the executable code that’s fixed for whatever reason. That new binary executable has different behavior than the old one. Or it might be completely new behavior that old ones didn’t have

I work in an updates group so I see it first hand. New code is applied to any files necessary. New services get installed/updated as needed. Cached files are deleted.

Well, lets put like that:

You have a toy from hm… the whatever season PowerRangers was last year. It was once a new thing, and were like that for some time, but then they released a new season of PowerRangers, and then your toy is not up to date to the TV serie, ofcourse they did release a new
set of toys with the debut of the new season, and these new toys may be the exactly same toy that you have just re-skinned, or maybe a toy somewhat similiar, but with a few new upgrades or even a totally new toy.

Softwares works somewhat like that, some updates will only change how it looks, others will be some bug fixes(patches, let’s say), and others will be a totally new software that came to replace the old one, that will be up to date with the developer new goals and/or new technologies.

Sorry for my broken english =)

I’ll take a stab at an analogy.

You’ve got a collection of cookbooks on your shelf that you bought and installed. Turns out there are some problems in various recipes. So back at the cook book company they get the writers to fix the problems in the various cookbook recipes. They collect these fixes and maybe a new recipe or two and put them into a new version of the collection.

Periodically, you cookbook collection will reach out over the Internet to the cookbook factory server and ask if there’s a new version. It will send in the request it’s own version (let’s s ay publish date)

Based on the version you gave it, it knows which books it needs to send down. Any change in a recipe in any book means that the whole book needs to be sent down. But any unchanged books can often be left unchanged.

These cookbooks that have been updated are put on the shelf in place of the old one, which is thrown away.

So in this example the recipes are code compiled into “books” which are libraries or executables. The whole shelf/collection of cookbooks is the application.

There’s two things that might need to get updated: The code, and any stored data.

When the code is updated, it’s really just installing the new version and uninstalling the old. There’s no sense in trying to make an upgrader that only changes what needs to be changed. It’s too hard, and download speeds are pretty quick now. However, large programs might be broken into separate chunks, and it might be possible to replace only certain chunks.

The ugly part of updating is always the data. Let’s say you’ve made an address book app, that’s ultimately a list of people where each person has data like name, address, and phone number. All of your users now have a data file somewhere that looks like:

[
{
name: “Alice”,
address: “123 Whatever St.”,
phone_number: “555-9876”
},
{
name: “Bob”,
phone_number: “555-1234”
}
]

Then you realize: crap, people can have multiple phone numbers and email addresses. Those need to be stored as a list instead of a single value! So you modify your program, but when users update, something has to go in and convert each existing phone number from a single number to a list with just that number:

[
{
name: “Alice”,
address: “123 Whatever St.”,
phone_number: [“555-9876”]
},
{
name: “Bob”,
phone_number: [“555-1234”]
}
]

So you write a script to do that and have it run after the new code is installed. Now you have version 2.0, hooray!

But then you realize: crap, people want to tag each phone number by what it is (home, cell, work, etc.). So it should actually look like:

[
{
name: “Alice”,
address: “123 Whatever St.”,
phone_numbers: {
home: “555-9876”
}
},
{
name: “Bob”,
phone_numbers: {
work: “555-1234”
}
}
]

But wait, when users upgrade, they haven’t added that info, so you’re gonna have to do something like call them `unclassified` at first and then write something special in the code to handle that and prompt users to enter what it is when they come across it.

And what if users are still on version 1 when you’re trying to release this upgrade to version 3? You can just run each data converter in series, and that’ll probably be fine for now, but what about when you get to version 50? What if version 4 adds more information to those phone number labels, and users are upgrading from version 1 or 2 where they don’t have those yet, so now you’re trying to update data that doesn’t exist?

This is why sometimes your data gets clobbered when you update. Either they didn’t think of some case and the data gets broken, or they just hoped they could get away with deleting your data and live through the outrage. And this kind of large-scale management is what’s really hard about software engineering.