Deploying an Apex class with a dependency on an older managed package version

Question

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"/>
</target>

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.

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:

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

Answer 1

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.

Answer 2

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.