Dealing with "forced upgrades" to web-services?

Question

I've just written a short article entitled Forced software upgrades in the land of web-apps

My question for Stackoverflow on this topic is, how would you go about allowing users to access old versions of your web-application (like GMails "Older version" button), and is it worth it?

Clarification: I am using the term "web application" very broadly, it could refer to sites like Stackoverflow, Reddit, or Lighthouse, etc. Anything site where it does more than simply display static content, really. I am not referring to anything resembling an API, where it is defiantly of benefit to retain backwards compatibility, say by including a version number in the URL (E.g GET /api/v01/posts)

Answer 1

It seems unclear to me if you're talking about web applications or web services.

If you are talking about actual WSDL-based web-services it'd be common to create a "compatibility" layer of wrapper classes to keep isolation between the underlying services and the webservice. Quite a few organizations demand that such layers be written from the start, to facilitate newer versions at a later stage. This is because you can really never change a published web-service in any way.

The newer versions get new url's.

Answer 2

I find it curious that it's considered "obvious" that old versions of the API should be supported, but not so the "front end" for normal users.

My wife had a real headache a while ago when the snapfish-powered photo prints site she uses suddenly started breaking in strange ways. It took us a while to figure out she needed a new version of Firefox, but until then the site was frustratingly unusable for her. Access to the "old version" would have been greatly appreciated. It's experiences like this which put people off web applications. At least on your desktop you can always reinstall the old version.

Answer 3

When providing a protocol for developers, a service provider really needs to provide backwards compatibility, forever.

Or at least, if they are ever going to break backwards compatibility, they need to give all the customers ample warning, a long overlap period where both are available and instructions on how the new protocol can be used equivalently to the old one.

---

For an end-user application, forced upgrades are the norm because it is a massive amount of extra work to continue to maintain legacy versions of the same application. Our company certainly does not give its end-users the ability to use old versions of the portal after an upgrade happens. Customers are generally told about upgrades, and in some cases allowed to review them (major customers, resellers and cobrand owners only in most cases).

Maintaining two versions of a user interface is a massive headache and no sane project manager would choose to go down that road. Developers would hate maintaining two interfaces and there would be more bugs to fix and the same bugs may need fixing twice. The QA work would probably double.