1) Will upgrading the build producing Org from Summer 13 to Winter 14 impact the two patch orgs (Created out of the main build producing Org currently on developing 4.2 version, but each patch org 4.0.X and 4.1.X has a different Org ID ).

2) Are the releases builds produced and published on app exchange by 4.3.X main org in winter 13 going to be compatible/ installable by customer orgs still in summer 13 or older versions? for eg: if we upgrade build producing Org from Summer 13 to Winter 14 and create a 4.2.1 build, can it be installed on any org on summer 13 ?

3) Will it impact/ prevent us from releasing patches (4.0.X and 4.1.X ) in summer 13 after upgrade of main org to winter 14?

4) Are there any compatibility issues known?

6) Is there any option/ possibility of rollback/ downgrade of the build producing Org from winter 14 to summer 13 org in case of issues with build or errors in installation by the customers?


Your developer edition cannot be willingly upgraded ahead of time, nor can it be rolled back once it is upgraded. Your patch organizations should retain the version they had at the point they were created, so any updates should be installable/pushable. Since they don't upgrade automatically, it won't create any compatibility issues. Note that you can't install a downgrade, so users using 4.2.1 wouldn't be able to install patches from 4.0.X or 4.1.X anyways; it's expected that 4.2.1 would incorporate the patches separately.

Once upgraded, any new uploads from that developer edition won't install in organizations running the older version. Normally, this means that there is up to 28 days where those packages can't be installed (the usual wait time is 7 to 14 days). Packages on na1 suffer from this effect the most, since na1 is updated before newer instances, such as na15. Developer editions on instances greater than na7, conversely, will generally be compatible with all other instances at any given point in time.

There aren't any major known incompatibilities, but this is the point of salesforce.com giving us access to pre-releases. As an ISV, you're responsible for logging into a pre-release, installing your package, and testing it to make sure it still works. Then, if you encounter incompatibilities, you should fix your code (if it's your own fault), or log a case (if it's salesforce.com fault), so that the issue can be fixed before the GA release of that version.

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.