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?

Can you request them to be on the same instances, e.g. everything on NA14?
–
Mike ChaleOct 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 ScottOct 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 ChaleOct 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.
–
Daniel BlackhallJun 26 '13 at 23:01

3 Answers
3

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

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.
–
techtrekkerOct 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 ScottOct 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.

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 ScottOct 11 '12 at 16:20