Generally speaking, once you have your integration classes generated for a specific set of API versions you can continue to use them almost indefinitely. As long as you don't need any features that are exposed in a newer API version there is now need to upgrade.
I say almost as there are two scenarios I've come across that will force you to update:
- Salesforce has dropped support for older API versions. This is fairly rare. To put this in perspective the most recent occurrence I can think of for this was Winter '19 dropping support for v6.0 and earlier.
- Salesforce accidentally introduces a bug in the API versioning that forces you to update. I'm thinking of the mess that tns:json caused with the Summer '19 v46.0 release.
When you do find the need to generate proxy code for the newer API version there is no need to keep the code to integrate with the older API versions. The only catch here would be if you need to deploy in the middle of a Salesforce release window. In that scenario there may be some orders on the latest release and some of the prior release. I've been fortunate that I can stage my releases until I know that all orgs are on the latest release.
Dealing with sandboxes can further complicate this.
So let's say i wanted to make an application that should work with any org. Unless something explicitly breaks, the old classes will be compatible without knowing the api of that org, either newer or older.
At the end of every release cycle there is a point where all orgs are running the same minimum API version of Salesforce. At that point you can safely use that API version anywhere. You can continue to do so into the future as well. The only catch is breaking changes and intentional deprecation of that API version. Thankfully both of those cases are very rare.
What you can't do is jump on the latest API release when it reaches a sandbox and then try and use that in all the production orgs. They won't accept API versions greater than their current release. Which makes sense.
How is that all related to the API of each object (when you save from dev console for example)?
That is a more complicated question. If you look at something like Apex classes and triggers, the Apex code in each will run according to the behavior defined for their API version.
In theory, you write your code against a specific API version and deploy it. It will then continue to run against that original API version and be unchanged by subsequent Salesforce releases. Have a read of What are all of the reasons why Salesforce customers should upgrade the API version on their Apex classes, triggers, and pages?