Support for multiple version of the API lead to crutches?

Question

API

Hello!
Suppose an application that works with the first version of the API can only define the BB tag [IMG=image.jpg].
Let's say the tag [VIDEO=//youtu.be/h3vd3g3] is added in the second version of the API
. the connection to the database is in any case common, say class Posts , then the classes of both versions work with this class. And he, accordingly, gives VIDEO tags, too. they are in the database.
I didn’t come up with anything better than how to create an additional method in the /api/v1/getPosts.php class that is executed after the Posts->getFromDb() method , it will look for VIDEO tags, delete the tag itself and leave only the link. And everything seems to be fine BUT ....
Suppose there is a third version of the application that works with the third version of the API, where the [QUOTE] tag appeared.
It turns out that when creating the third version of the API, I must return to the first version and add one more tag to delete to our crutch method, and in the second version also create the same method that will only delete QUOTE
Is this a normal practice?

Answer 1

I may not understand, but in your example, each next version expands the functionality of the previous one, which allows the client of the first version to safely use the third.
In this case, there is no need to separate them somehow.
That's when the next version breaks backward compatibility (by changing / deleting fields, entrypoints, stricter validation), then in this case you need to have two different versions of the API.