Our views on backward compatibility start with asking these questions:
- Question 1: How many apps are we going to break externally?
- Question 2: How many apps are we going to break internally?
- Question 3: What is the cost of providing backward compatibility and repairing (and test) all the broken apps?
Let's look at an example:
We have a public web service /ssw/webservices/postcode/
If we change the URL of this public Web Service, we'd have to answer the questions as follows:
- Answer 1: Externally - Don't know, we have some leads:
We can look at web stats and get an idea.
If an IP address enters our website at this point, it tells us that possibly an application is using it and the user isn't just following the links.
- Answer 2: Website samples + Adams code demo
- Answer 3: Can add a redirect or change the page to output a warning Old URL. Please see www.ssw.com.au/ PostCodeWebService for new URL
Because we know that not many external clients use this example, we decide to remove the old web service after some time.
Just to be friendly, we would send an email for the first month, and then another email in the second month. After that, just emit "This is deprecated (old)." We'll also need to update the UDDI so people don't keep coming to our old address.
We all wish we never need to support old code, but sometimes the world doesn't go that way, if your answer to question 3 scares you, then you might need to provide some form of backward compatibility or warning.
From: John Liu www.ssw.com.au
Subject: Changing LookOut settings
The stored procedure procSSWLookOutClientIDSelect (currently used only by LookOut any version prior to 10) is being renamed to procSSWLookOutClientIDSelect. The old stored procedure will be removed within 1 month.
You can change your settings either by:
- Going to LookOut Options -> Database tab and select the new stored procedure
- Upgrading to SSW LookOut version 10.0 which will be released later today