Return to Answer

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, and 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, A could show a warning 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."

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.

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.

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, you may be inclined not to support a five years old version of A with B when only 1% 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.

It will also give you the opportunity to implement a smooth transition process to a newer version. For example, A could show a warning 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."

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.

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, and 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, A could show a warning 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."

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.

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.

That 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 next quarter.

Of course, you may be inclined not to support a five years old version of A with B when only 1% 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.

It will also give you the opportunity to implement a smooth transition process to a newer version. For example, A could show a warning 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."

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.

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, you may be inclined not to support a five years old version of A with B when only 1% 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.

It will also give you the opportunity to implement a smooth transition process to a newer version. For example, A could show a warning 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."

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.