1

For instance, in the case of PostgreSQL, it is entirely acceptable to use a newer client to connect to an older server; but if you do the opposite, using an older client to connect to a newer server, you would get a warning.

My gut feeling is that, by off-loading the responsibility of ensuring backward-compatibility to the client, it helps keep the server codebase simpler and therefore ensure the server's stability and bug-freeness.

Are there other factors?

In the case of instant messaging systems such as WhatsApp, Slack, etc, we often find that the reverse is true: you can use older clients to communicate with the newer server up to a certain period. That seems to be out of necessity because there are so many users and the IM service provider can't anticipate when the users update their client software. I'm not sure whether the fact that there is usually[1] only one server provider is a contributing factor.

[1] I know that some instant messaging systems can be deployed as private instances.

Improve this question
0

2 Answers 2

Reset to default
1

Shearing Forces

A shearing force is a force that slows down or speeds up the rate of change in a component. Where these forces change create shearing boundaries and between two boundaries is a shearing layer.

Database servers are built to maintain data. Upgrading the system managing that data is a fraught process, especially when the data format changes. Then there are the new features that get rolled in and trialled in a global beta. Obviously many database admins take a dim view of this. The data must be protected. Better to have a stable system that receives bug fixes, but no new features. And they like to keep it slow because it takes time to verify that the data has been maintained consistently between breaking versions.

Conversely the interface to that data and how it is bound in a given language does not have the same forces. Here it is more important to get not just the bug fixes, but the improved features.

For the messaging server/app, well one is on owned hardware, the other is not. You can deploy to your own hardware every few minutes if you build the right fire-hose deployment line. Try getting a user to do the same - I find it annoying enough that steam forces an update just about every time I login. Having to wait 10 minutes to update a messenger app... whoops there is an email app over there that I don't have to wait for, and I can send more than 180 characters.

Not to say that you can't have evergreen database servers, or always up to date messenger clients. Just pointing out the forces generally on these components that prevent faster change, or encourage slower change.

Improve this answer
1

This depends mostly on what combinations of outdated client or server software versions can be expected and should be accommodated. You should also be aware that the main thing is the API version, not the version of either client or server software. It is good practice to keep APIs stable so that clients and servers can be improved independently without fearing incompatibilities.

Database servers tend to run older versions because upgrading an installation means downtime and increased risk. Consequently, clients are written to communicate with older servers without problems. In reality, it works the other way around for some version steps, too, since applications compiled with one version of the client library often will not be rewritten to use the newest version just because the server is upgraded.

In the case of services provided by a single entity your observation is probably spot on: the server needs to accept older clients, but you will rarely need to support older server versions in newer versions of the client. If this is possible as in private installations of the server software, you either require your clients to run a matching older version, too, or you compile support for some older server version into the client.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.