How to support multiple mobile application versions with the most up-to-date server deployment?

Question

I'm trying to figure out a scenario, but I can't find any relevant information on the web.

Let's say I am deploying an Android Application (v1.0.0) with the backend (v1.0.0). At some point, I will make some changes and update the app to v1.0.1 and the backend to v1.0.1 and they will work perfectly. But how can I also support the previous version of the application (maybe the new server version provides another format of response for one specific request)?

I thought of having separate deployments for every version of the server, but for many updates, that would mean a big resources impact. Also, forcing the users to update doesn't seem a good option in my opinion.

Answer 1

Essentially you can go multiple ways of doing it. Really depends on your requirements, but usually the reality is a mixture of the things below.

As a rule of thumb, think in data model that will be held compatible. If the contract can not be kept or your realize major changes are needed, introduce a new version of API. If old clients can not be supported, force update. You can also agree on a policy on how long to support each previous versions and then force update, this will make your life much easier and simpler, than maintaining tens of versions of APIs.

Backwards compatible data model

1. You must think backwards with each release:

   Think of incremental modelling with each release cycle. So you can keep things.

2. When you forget about it and you need to switch behavior based on data:

   Happened to me in my trainee years. Simply you have to decode which version it might be, based on the data if you forget to add protocol version. From the beginning you can always have a version field on the data. Moreover, you can also add a set of compatible parser versions.

Include protocol version in data:

{
    "data": [ arbitrary data model],
    "protocolVersion": "v1"
}

Based on the protocol version, you can decide how to process the data on the server side. You don't need to keep client version in mind, only the protocol's. Since it can be that you release: 1.0.0, 1.0.1, 1.1.0, and you only change protocol in 1.2.0.

But I think the problem is the that as data changes subsequently, so does behavior on server side processing.

Versioned API

1. Sometimes you see different paths for major versions:

   • /api/v1/query

   • /api/v2/query

Used when backwards compatibility is broken or after total reconsideration. Therefore not every version will have an increment.

2. Use a query parameter with the client version:

   • /api/query?v=1.0
   • /api/query?v=1.1

Similar to previous one, just written differently. Although I think this is not the way you want to go down.

Track client releases and used service versions

In reality there are multiple requests and multiple versions of services being used all times per one client version. This makes things even harder to maintain.

All the time, document and track. Version and release management is very important. Know the git hash from which version you built, many time it can get confusing and you just changed only one parameter after release as a quick fix and the day after nothing is compatible anymore.

Map all service versions to the client version at each release, know which commit you really built and use tagging and release management.

Test everything before each release

Have clear requirements for your backwards compatibility. Maybe you only support two older versions, then test with all the two clients, new client with the to be released server. Document everything. And when you meet your criteria for release, go with it.

Summary

Reality is a mixture of solutions. Have clear requirements on the backward compatibility. Therefore you can test before each release. When it is necessary, force update. Keep track of releases, and document each client versions with all the services being used with their versions.