SOAP API, wsdl, wsc and class versioning confusion

Question

We are a small team creating an app that integrates with Salesforce (any org). We are trying to clear up some confusion about how the entire versioning system works, so that we can support it long term.

So, from what i have understood so far, every class or trigger in salesforce has an API version. The rest and soap apis respectively have versions that handle the classes and triggers of the same versions (or earlier?)

Now, to integrate with soap, we need to use the WSDL (which has a version) and generate the classes using WSC (which also has a version). Then we create the partner, tooling and metadata java packages using the corresponding WSDLs (all of the same version as the above).

My question is, every time a new version comes out, we have to do the entire process from the start but for version 46 -> 46 ? New jars, new wsdls and so on? And if so, the best practice is to have a package of the generated classes for each version? When for example executing a tooling query, how do we know which version of the java classes and soap api to use? Thank you in advance.

Answer 1

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:

1. 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.
2. 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?