I'm working on automating the deployment from source control to a sandbox that will be used by a single developer.

I want to be able to deploy to the sandbox so that it mirrors the chosen source control branch.

The following ant script is being used with the Force.com Migration Tool.

<target name="deployCodeCheckOnly">
  <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}"
     maxPoll="${sf.maxPoll}" deployRoot="SomeProjectFolder" checkOnly="true"/>

When run it is coming back with the error (among others):

*********** DEPLOYMENT FAILED ***********
Request ID: 0AfO0000005sK3DKAU

All Component Failures:
1. classes/SomeClass.cls-meta.xml -- Error: The specified Package Version number does not exist for that Package: loan, 1.1794

The current version of that managed package from the Installed Packages page is 1.1806.4.

The current Version Settings for the Apex class in Salesforce lists the version as 1.1794. enter image description here

I assume I can't install the older 1.1794 version of the managed package as the sandbox org already has a more recent version.

On the Package Details page I found this: First Installed Package Version greater than Apex class version

The sandbox is reporting that the "First Installed Version Number" for the package is 1.1799 while there are multiple Apex classes that require version 1.1794.

How is this even possible?

Oddly the developer console is able to edit the class (using the tooling API). MavensMate can save it when using the Tooling API but not with the Metadata API.

Should I just update the .cls-meta file to match the minimum version listing in the Org?

Update: I've encountered this again in another org. I think it is related to refreshing a sandbox. The steps would be something like:

  1. Install managed package version 1 in a sandbox.
  2. Perform development against managed package version 1.0 in sandbox. Creates Apex classes with a packageVersion with majorNumber 1 and minorNumber 0
  3. Create a new version 1.1 of the managed package.
  4. Install v1.1 of the managed package in production.
  5. Deploy the Apex class with the dependency on v1.0 to production.
  6. Refresh the sandbox from production. The Sandbox will be productions "First Installed Version Number" of 1.1.
  7. Subsequent attempts to update the Apex class in the sandbox will fail with

    The specified Package Version number does not exist for that Package: Namespace, 1.0


2 Answers 2


We deliver a combination of managed packages and non-managed components to customers (via various dev and sandbox and production orgs) and often have to search and replace the version meta data for the non-managed classes and triggers because the target org is missing the exact version number. Seems wrong given that a later version of a managed package is forced to be API compatible with an earlier version; requiring the managed package to be of a greater than or equal version would make more sense. Perhaps someone has some insight into why the version match instead has to be exact...

So if this is your situation, yes change the version information in the class and trigger meta files; we usually change it to the current version not the earliest.

  • I was going to move the version numbers forward to the minimum available version only as I didn't have details about how the package in question was changing between releases. I'd be jumping forward 12 releases to go to the current installed version. Either way I guess I'll have potential issues, might as well get as current as possible. Commented May 22, 2015 at 1:18
  • @DanielBallinger My assumption is that unless your code is invoking global methods from the managed package (in which the package author has carefully versioned the behaviour), the version will have no impact. Though perhaps I'm wrong and a trigger in the managed package sees the Version of the managed package that is set on the originating class.
    – Keith C
    Commented May 22, 2015 at 8:32

In addition to Keith C's answer (which is the same approach I ended up taking), I used XMLTask to set the version numbers as part of the migration process.

Here is the question I asked, which has a guide on how to use XMLTask to achieve this.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .