In the couple weeks between when Salesforce upgrades the first instances and when they have finished rolling the new version out to everyone, it is a struggle to get a new package out. Currently, our packaging org has been upgraded to Winter 13, but the orgs we have designated for QA are still sitting at Summer 12. So, the attempt at installation of a new package for testing in our QA org results in the following error:

Mismatching Versions

The AppExchange Application or component you have selected is not yet available on your instance of salesforce.com. Please check back in a few days to retry the installation. Press the back button of your browser now and bookmark the AppExchange Directory page so that you can find it later.

Consequently, if we need to get an emergency release to a customer, they are out of luck if their org is still waiting for the new Salesforce release.

Is this something we just have to live with or is there a way to work around it?

  • 1
    Can you request them to be on the same instances, e.g. everything on NA14?
    – Mike Chale
    Oct 11 '12 at 1:32
  • I never thought about requesting an instance change. Do they always upgrade the instances in the same order? i.e. will NA14 always be among the last upgraded? That may solve the second issue if everyone else gets upgraded before or at the same time as our packaging org.
    – Rob Scott
    Oct 11 '12 at 5:17
  • I have no idea, but if all of your orgs are on the same instance it would keep them on the same version at least.
    – Mike Chale
    Oct 11 '12 at 12:56
  • @MikeChale I requested for all our dev orgs to be on the same server and was rebuffed. Salesforce claims they will not move servers unless it is a production org. Jun 26 '13 at 23:01

I can't speak for Managed Packages, but I know that when using the ANT tool and with Changesets that the few weeks window as you have orgs across versions poses real challenges.

The only solution I've had is doing things like excluding components that are incompatible from the package.xml/changeset in order to get the release done and then manually configuring them if needed the target org.

If neither of those options are available in Managed Packages, you may be out of luck :(

  • 1
    I don't think there is another way out save for planning ahead. Salesforce publish a path to Winter '13 kinda thing, whereby they let you know when you need to refresh : not refresh to be on the latest release. This would work for sandboxes. (So this hopefully helps with your internal packaging-> QA situation)Production orgs will get upgraded in their own sweet time. Oct 11 '12 at 7:14
  • 1
    Packaging orgs are not sandboxes and get upgraded the same as other production orgs. And unfortunately there is no planning ahead for customers running into critical issues. Normal release cycles can and should be planned around the salesforce release window.
    – Rob Scott
    Oct 11 '12 at 16:27

We've run into this issue a number of times. Just recently again our release cycle coincided with the Summer '13 release cycle. Initial versions of some of our packages were packaged prior to the first Summer '13 upgrade weekend, so they were packaged under Spring '13. But our packager orgs were on nodes that were scheduled to be upgraded on the first weekend of the Summer '13 release. We wanted to push out these packages to some of our subscriber orgs on a limited basis. We had to make sure that we chose subscriber orgs that were going to be upgraded to Summer '13 in that first weekend, just to make sure that we would be able to re-package and upgrade them in the event we found critical bugs after our release.

I do not believe there is any workaround for this. The only thing I can recommend it to try not to have your package releases coincide with Salesforce releases.


You will need to modify the accompanying XML files to change the version back to the same as the one in production. You can also do this in the UI prior to creating a change set/pulling with ant.

  • This has nothing to do with the meta files and their API versions. Leaving all meta files the same and uploading a managed package in an upgraded org will precluded you from installing the packing in a non-upgraded org.
    – Rob Scott
    Oct 11 '12 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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