Cobos and backward compatibility

Cobos is a product composed of two main parts:
– a set of Eclipse plugins as the client side
– a set of scripts on the Mainframe server – yes, you have noticed that there is no Cobos server, simplifying the installation on any mainframe.

Since the very beginning of the project, we have decided to give our users the opportunity to upgrade client and server independently, to deploy the client upgrades without constraints, to validate a new server version quietly, or simply to put it online for a few well chosen users, etc …

So, how do we make it?

Well, we rely on what is known as backward compatibility – a well-known concept by our IBM friends when they designed the mainframe architecture in the 60’s 🙂

For Cobos, backward compatibility means in fact backward AND forward compatibility (see https://en.wikipedia.org/wiki/Backward_compatibility)

Let’s define backward compatibility:
* The new server is compatible with the previous client version.
* The new client is compatible with the previous server version.

Forward Compatibility:
* The old client is compatible with the new server version.
* The old server is compatible with the new client version.

In fact, we have to deal with this concept when we are developing a new version. I know developers who have made brain knots with that, lol.

Still, it is not that complicated, but we just have to be careful.

1st point: knowledge of the version of the other component:
The server notifies the client of its version level during the connection.
The client announces its version level when sending a request to the server (all queries are marked with the client version).

2nd point: adapt yourself to partner version:
It is a bit more complicated because you can not do anything.
From what has been said previously, there would be 4 cases:
– customer side:
If I have an older server in front of me, I have to adapt some of my queries to conform to the expected API format and hide in the user interface the features not available on the server side.
If the server is at the latest version, we have the same version, everything is fine.
If the server is at a higher version, that is its problem, not mine.
– server side:
If I have an older client in front of me, I must continue to process his queries in the “old-fashioned” way to fulfill the previous version of the application protocol.
If the client is at the same version, everything is fine.
If the client is at a higher version, it is up to him to be careful, this is not my problem.

So, there are only 2 cases finally – or are there really 6 cases to manage? We can notice that forward compatibility is ensured by the backward compatibility of the partner – I leave you to think about it – so there are actually only 2 cases to be taken into account.

For Cobos, we made a choice based on the following simple (but binding) principles:
– we support 2 major versions (current version and previous version).
– we guarantee that the current version will be supported by the next version (I do repeat exactly the previous sentence but it is better if it is written).
– there are no changes in application protocol during the life of a major version, our APIs must therefore be well designed to be as stable as possible but it is for another story.

Et voila!