Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

From time to time I noticed that my meta files for Apex and Visualforce get changed to include specific references to managed packages version information as shown below. However, my classes don't reference anything in the managed package. Does anyone know how the metadata API determines whether or not to include this?

<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>20.0</apiVersion>
    <packageVersions>
        <majorNumber>3</majorNumber>
        <minorNumber>72</minorNumber>
        <namespace>Apttus</namespace>
    </packageVersions>
    <status>Active</status>
</ApexClass>
share|improve this question

1 Answer 1

When: It is basically the act of installing any managed packaging in your development packaging org. The platform seems to rattle through your metadata files and apply this (it's also evident from the Versions tab when viewing Apex via the web ui). I agree it does seem a bit over the top given you're likely not referencing any components from such packages. The same is not true if you upgrade them however, the package version stays the same as when it was first installed (another recent post here as well).

Why? I suspect the platform is doing it to maintain some kind of consistent versioning perspective at runtime that may be needed directly or indirectly as your code executes. For example if you use Apex Describe over all org objects and fields, the information it returns when it encounters packaged objects will remain consistent, after upgrades to those packages. Or if your package is installed in a subscriber org with a later version of such packages available.

Packaging Of course that above scenario in subscriber orgs does assume your package one way or another becomes dependent on such packages for the platform to even consider recording such information once packaged. Fortunately the packager is a little more considered before making package dependencies that just simply them being installed.

Summary In short it's a bit shotgun in your packaging org, but more refined to retaining versions to packages only where explicit references are made when producing your final package.

Hope that makes senses.... (it's a bit late in the UK) ;-)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.