It's that time of the year again (one of three times, actually), where you might be attempting to make some fixes in a sandbox that has already been upgraded to the next release and uploading a Change Set from that org to Production where the next release hasn't been applied yet.
This change set requires the "##.#" or later platform version
- Sandbox 1: Summer '15
- Production: Spring '15
By chance, did you get to this point by following a normal deployment pattern? You know, where you deploy from a developer sandbox to a full sandbox and are now ready to deploy to Production?
Chances are, the full sandbox you deployed to was also upgraded to the next release. You probably already know that upon upload, a Change Set's components are locked down. But did you also know that the API version of that Change Set is set and locked based on the target org's API?
This means that when you uploaded from your developer sandbox to the full sandbox, the Change Set was set to the latest API version and is now locked to it. When you attempt to upload this same Change Set to production, you get the "This change set requires..." error message.
Out of luck? Nope! Just "Clone" the Change Set and re-upload.
When you create a new Change Set by cloning, you're creating a new instance of the Change Set with all the original components and is unlocked so new components can be added. At this point, the API number has yet to be set as well.
This time, don't upload to a sandbox first; upload it directly to Production so the Production org's API number is set on the Change Set and the upload is allowed.