Supporting old operating systems and old versions means you have more (and often messy) code, with lots of if or switch statements. This might be OK for you because you wrote the code, but down the track when someone else is maintaining it, then there is more time/expense needed.
When you realize there is a better way to do something, then you will change it, clean code should be the goal, however, because this affects old users, and changing interfaces at every whim also means an expense for all the apps that break, the decision isn't so easy to make.
Our views on backward compatibility start with asking these questions:
Let's look at an example:
If we change the URL of this public Web Service, we'd have to answer the questions as follows:
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 probably all prefer working on new features, rather than supporting old code, but it’s still a core part of the job. If your answer to question 3 scares you, it might be time to consider a backward compatibility warning.
The stored procedure procLookOutClientSelect (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:
✅ Figure: Good Example - Email as a backward compatibility warning