I've a managed package, which I'll call Package A, that has a dependency on another package which I'll call Package B. The meta.xml files for the classes in Package A have the majorNumber and minorNumber for Package B set with the highest value being 5.15. The org where the build for Package A is taking place has a higher version number installed for Package B, in this case the version is 6.27.
When Package A is built it is dependent on version 6.27 of Package B and not 5.15 as the meta.xml files in the Package A state.
Investigating this further, uninstalling/installing Package B to version 5.15, and building another version of Package A with no code changes results in the newly built Package A being dependent on 5.15 of Package B.
What I'm wondering is what is the expected behaviour in these circumstances? Is the installed version of Package B in the build org used as the minimum version of that dependent package for deployments of Package A?
Best Answer
Background to packageVersions in meta-xml files.
Your observations about about the Metadata XML files are correct, they are used to stamp the intended version of the platform and any related managed package components the Apex code or VF page is dependent apone. Prior to Summer'13 this stamping was rather over the top and occurred on all classes and pages regardless of if they made component references or not. Fortunately this didn't extend to the upload process, where the true references drove the packages actual dependencies. Since Summer'13 the logic in the platform has improved such that it now correctly states only when components are explicitly referenced. This answer discusses this in more detail, Class and Trigger packageVersions elements missing in meta XML files using Force IDE.
When should the Version Information be Updated?
I've checked the Metadata API developers guide and while it does go into some detail, it only describes the values in more detail, not the implications of them. I've also reviewed the ISV Guide, which references Extension Packages in a few places as solutions to building apps to support different org editions, product features and Security Review implications. The best information I've found is this, which talks about Understanding Dependencies and also this information from the web UI where you can edit the version, Defining Apex Classes.
It also goes on to say this...
My expectation from my experience (we have developed a number of base and extension packages) is that the version information (like the platform API version also in this file) remains static unless you as the developer decide to change it and opt into new functionality provided by the base package/s.
This level control is critical to how the extension package interacts with the base package at runtime and at compile time. For example at runtime the base package can determine at runtime via System.getRequestVersion what version the caller is expect it to behave like and omit execute of functionality not available at that time. You can read a bit more about this interaction here.
Thoughts on your experience...
So if the version of the base package was implicitly updated in your extension package metadata files by installing a more recent base package version into the extension package development org. Then this would take this decision out of the developers hands and risk regressions in the extension package as new features surfaced from the base package.
So what you have described feels a little like a bug, possibly a side effect of the auto dependency correction introduced in Summer'13. Though the other thought I have is that you said you uninstalled the base package and reinstalled a later version. In this case you must not have had any dependencies in your extension package i assume to be able to do so? If so then once you install the base package again and then made new references they would as per the docs above, default to the latest version of the package unless you explicitly set them to an earlier version.
Hope this lot helps! :)