API Versions not deploying

[Justin Julicher]

When deploying all metadata using the current context as the deploy the API version is not getting updated on the target sandbox .

[Scott Wells]

Justin, if I understand correctly, it sounds like you're expecting deployment of metadata that targets a specific API version via the meta.xml file, e.g., Apex classes/triggers, to update to the API version associated with the connection. Is that correct? If so, IC won't do that. For many teams it's critical that a certain subset of metadata target a specific older API version even if newer metadata target the latest API version...at least until the former set can be updated for breaking changes in the newer version. IC will create new meta.xml files using the connection's API version, but it will never auto-update existing files.

If that's an incorrect read of the issue, please let me know.

[Justin Julicher]

Hi Scott

‌

Sorry if this wasn't clear.

‌

I updated the API version in the local files associated meta.xml and when deploying the file to the target sandbox is not updated.

Eg. Sandbox class was at API version 23, local 46. When I deployed that file the sandbox code changed but the API stayed at 23.

‌

Thanks

[Scott Wells]

Ah, I see. Thanks for the clarification. Any deployment via the Tooling API does not include the meta.xml files. That's not how that API works. As a result, if you have the Tooling API enabled for the supported metadata types, deployment of the following will not include the meta.xml file(s):

1. Any combination of Apex classes/triggers and/or Visualforce pages/components
2. A single static resource
3. A single Aura bundle file

If you deploy any other metadata file(s), or any combination of the files listed above, IC will deploy via the Metadata API because the Tooling API will not be able to handle that payload. Also, if you explicitly save a meta.xml file--either by showing them in the project view, navigating to them explicitly, or switching to the Metadata subtab--the Metadata API will be used for the save.

I hope that helps explain the behavior. Let me know if not.

[Justin Julicher]

Hi Scott

I see that clarifies it a lot.

So I edited the API version using the meta sub tab and then deployed that file. From your explanation then that should have deployed the meta xml file? Excuse me if I’m being dumbed it was a late night getting a deploy out of legacy code.

‌

Thanks

[Scott Wells]

That's what's supposed to happen, yes, but I just tried it and I've introduced a bug recently. I'll take care of it for the next build. Ugh...sorry about that!

UPDATE: Fixed for the next build. Now if you save a supporting meta.xml file, it again properly deploys the companion metadata file and the meta.xml file via the Metadata API.

[Justin Julicher]

Thanks!

I wasn't sure if I was going crazy or not!

[Scott Wells]

No, but the jury is evidently still out on me...can't believe I introduced that regression...sigh. I'll see if I can get the updated build out tomorrow...Thursday at the latest, though. It has some nice editor enhancements--parameter hints and string literal injection for dynamic SOQL and regexp--as well as a number of other fixes. I just want to make sure it's well-tested. The quickest workaround in the interim is to deploy the files for which you want version updates alongside at least one other file that can't be deployed via the Tooling API. That will force deployment via the Metadata API...or just disable deployment via Tooling API temporarily.

[Scott Wells]

Delivered in 2.0.6.7.