14

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?

5
  • 1
    Can you request them to be on the same instances, e.g. everything on NA14?
    – Mike Chale
    Oct 11, 2012 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, 2012 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, 2012 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, 2013 at 23:01
  • Still an issue, almost 10 years later. Our partner dev org got upgraded 1 month earlier than customer production orgs. I can't believe we run the risk of not being able to do deployments to customer orgs for 3 full months per year. Why can't we opt to move to an instance that is guaranteed to always be in the last batch? Sep 29, 2021 at 13:33

3 Answers 3

2

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 :(

2
  • 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, 2012 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, 2012 at 16:27
2

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.

-4

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.

1
  • 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, 2012 at 16:20

You must log in to answer this question.

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