I had this one user who kept using an old report. It used a terribly provisioned db account and had to be changed.
We created a v2 that was at feature parity to v1 and told users to move off of v1. Slowly but surely it happened.
Except one user.
We put up nag screens. Delays on data return, everything we could go “carrot” them to the new version but they stuck with it.
Eventually I called the guy and just asked him, “Why are you still using the old version?”
His answer, “no one ever told me about the new version.”
I asked him if he got our email. He said no. I forwarded it to him.
“Oh.”
I asked him didn’t you read the nag screens? He said no.
I asked him, “The page doesn’t allow you to move on until you wait 90 seconds. Why didn’t you read it?”
“I didn’t think it was important.”
I learned an important lesson that day: never wait for all users to move. Once you have enough, start doing scream tests.
Bastard user from hell
location /old_api { redirect /new_api }(can’t be bothered to check the syntax).
If you have a major version change, it means that old API calls will break against the new API, assuming they are accurately following semver.
You’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
I remember my engineer being such a hardass on using v2 of our API and when I went to implement a feature, v2 didn’t even have ANY of the endpoints I needed
I don’t get why anyone would publish v2 when it not really on feature-parity. Do companies really start releasing v2 endpoints slowly?
it’s called the strangler pattern, where the new version is layered on top of the old and gradually replaces it.
it usually doesn’t work.
