Best way to handle versioning between a desktop product and a cloud product when one depends on the other

Question

Let's say that there are two products, product A and product B.

• Product A is a desktop product that customers download and install locally on their machine. This product follows a typical versioning process where quarterly releases are sent out to customers to install at their own discretion. For example, 2023.05 would be the version sent out to customers in May of 2023. Customers can choose to download and install this new version or they can remain on their current version.
• Product B is a cloud product done as a simple cloud API. The versioning for this product lives in two environments: development and production. If a developer needs to add functionality, they will make the changes locally on their machine and make a pull request into the git branch representing the development environment. After testing has a go at the changes in the development environment, a pull request is made into the master branch which represents the production environment.

Now for the wrench. Product A depends on product B. When in-house testers are testing a development build of product A, product A will ping the development version of product B. Any releases of product A ping the production version of product B.

My question is this: Is this best approach to versioning in product B? What is the industry standard on this? How could this be improved?

This versioning for product B has been okay for us for the most part. We just need to make sure we don't make any breaking changes to product B when we do updates to it. As for a better versioning system, I have a few ideas.

• Implement a versioning system identical to product A in product B. Each quarterly release of product A would use the URL corresponding to the same quarterly release of product B. The only issue I see with this approach is that each quarterly release of product B would require a new set of cloud resources to host said release. In essence, we'd bloat our cloud resources. Bear in mind that performing a routine cleanup of cloud resources based on whether any of our customers are using a certain version of product A is trivial.
• Use the same versioning mentioned above but instead of creating new cloud resources for each quarterly release, we'd require that product A send in its own version to product B. Then product B would change its behavior based on this version that it received. This approach avoids cloud resource bloat. Instead, it bloats the code as each change made to product B needs to appear as a new file/function in the code as to not change any code already used by previous versions of product A.
• Force our customers to upgrade their version of product A once a new release is available.

What do you all think?

Answer 1

The most "user friendly" solution is to establish a mostly stable interface between A and B and keep B as backwards compatible as possible over longer periods of time with any new version deployed to the web.

This does usually not hinder you to implement new features in B, even when only newer versions of A can use them. You may implement a mechanics where A can ask B if a certain feature is available, and offer the related feature in the UI of A only in this case.

Backwards compatibility gives users of A the opportunity to work with the version they are happy with as long as they can. It gives them also the opportunity to switch back to an older version of A when it turns out the new version has some annoying bugs your team is going to fix only with the next version which is released next quarter.

Of course, this has a drawback. Over time, you will produce some legacy code in B which you want to get rid off sooner or later, but you cannot without sacrificing backwards compatibility. Of course, you may be inclined not to support a five years old version of A with B when only 5% of your user base still uses that old version. Hence you should keep track which version of A really is in use, and yes, A should always send its version number to B. This gives you the opportunity to check if you really need to support deprecated features in B, and how many users could be disturbed by forcing them to upgrade.

It will also give you the opportunity to implement a smooth transition process to a newer version. For example, when A sends its version number to B, B may send a reply message like *"You are still using Version 1.0, which will not be supported by service B next quarter any more. Please ask your administrator to install version 5.0 or newer." - so A can display this message to the users.

However, I would only force users to upgrade to a newer version when they really must and you definitely cannot affort to stay backwards compatible any more. I cannot tell you what a reasonable time interval for such forced upgrades is in your case, but when the installation of an upgrade involves some manual effort of an external IT department in the user's companies, better plan for years, not for quarters.