API Versions in Salesforce - All You Need to Know

As a feature of a controlled Metadata API delivery and source control procedure, it is essential to see how API forms impact functioning examples, particularly where groups of engineers share source control storehouses (Git or others) and arrangements are performed utilizing Ant contents, Jenkins, or other consistent joining devices.

This post thinks about how the Meta information API (alluded to in this archive as "the API") adaptations influence this cycle and how it ought to be utilized related to an oversaw source control measure (alluded to in this report as "the Git Repo" yet it applies to others too).

Each time Salesforce discharges another application form, its API adaptation is refreshed too. At the hour of composing we had quite recently delivered Summer 2013, which presented API form 28.

This API variant implies that when you send changes utilizing the API (for example utilizing the Eclipse Force.com IDE module) and use adaptation 28, your objective SFDC Org will convey these progressions with the rationale it partners with that specific form of the MetaData API (28). So for instance, rendition 28 presents another field on the article ApexPage called isConfirmationTokenRequired.
On the off chance that you attempt to transfer an Apex Page which contains that field and you are attempting to do so utilizing API form 27, your sending content will fizzle since that field isn't known for that API Version. Then again, on the off chance that you would transfer a similar document indicating API variant 28, it would turn out great.

A critical standard to comprehend is that while SFDC may deliver adaptation 28 of the API, the organization rationale related to rendition 27 is as yet accessible for use as long as you power the API to utilize form 27.
In Eclipse, utilizing the Force.com IDE the rendition of the API being utilized is determined in the ./src/package.xml document. Open it in a word processor look to the base and you will discover a line like: <Version>28.0</Version>

It is imperative to take note that your form of Eclipse will be unable to convey MetaData documents with an API adaptation that is higher than the one upheld by your Force.com IDE module.
So on the off chance that you are utilizing Eclipse with Force.com IDE form 27, you will most likely be unable to convey MetaData records with API variant 28. The most recent variant data on the Force.com IDE and how to update can be found here.

This idea may prompt utter disarray and various blunders if the groups are not steady with which API adaptation they are utilizing.

Pooja is an Apex engineer. She's been utilizing Eclipse for around a half year and the Force.com IDE API rendition she is utilizing in Eclipse (package.xml) is form 27.

Sway joins the group – introduces Eclipse, introduces the force.com IDE, and invigorates his current circumstance from an as of late delivered SFDC organization which is running Summer 2013. His package.xml document will in this way contain API variant 28.

Pooja and Bob are dealing with a similar undertaking and offer a similar Git Repo. Pooja is dealing with an Apex Trigger: Account_Update while Bob is chipping away at a trigger Contact_Update.

Situation 1

He's utilizing API adaptation 28 so the Apex Pages he downloads will incorporate the new isConfirmationTokenRequired field.

He makes his code changes to the contact trigger and registers them with the Git Repo.

Pooja refreshes her (nearby) storehouse from this Git Repo, so downloading Bob's Meta-information which incorporates Apex Pages, including the field isConfirmationTokenRequired and the progressions to Bob's contact trigger.

Pooja rolls out certain improvements to her record trigger and registers them with Git.

Pooja attempts to convey changes to the objective SFDC organization utilizing Eclipse, yet they will fall flat since her framework is arranged to utilize API form 27.
The objective organization will gripe that the field isConfirmationTokenRequired she is attempting to transfer is certainly not a worthy Meta information field for this API rendition.

Situation 2

Weave and Pooja stay up with the latest by reviving from the objective organization – not the Git Repo.

This situation will prompt comparative issues when Pooja is the last individual to check in her progressions to the Git Repo as the Ant Script executing after that submit will get Pooja’s API adaptation (27) while likewise attempting to send Bob's progressions which incorporate the isConfirmationTokenRequired field which is obscure to that API form.

In the above situations, the Git Repo will contain conflicting forming data where meta information for adaptation 28 (isConfirmationTokenRequired) exists along with Pooja’s (she was last..) package.xml document, which contains rendition 27.
Obviously, this is bothersome which ought to be corrected at the earliest opportunity. Generally speaking, the whole group (counting none designers) sharing a source control archive need to utilize a similar adaptation of the Metadata API all through.

There are two clear manners by which to determine the issues in the above situation:

In light of a legitimate concern for progress and to keep away from any regressive similarity issues – I will disregard the primary alternative as it appears to be counterproductive to minimization to an old rendition of the API!

So to get Pooja in a state of harmony with Bob:

Sway submits every one of his progressions including his trigger Contact_Update to the source control framework (so package.xml form is 28) – So ensure that the last individual to focus on the Git Repo is the one with the objective/new form of the API!