+ Start a Discussion

Maint. releases to v1 while v2 under development?



I'm about to release v1 of a managed package. Once this package is in the wild, I'll need to make bug fixes and do maintenance releases. At the same time, I will be building v2 in a separate code base / branch. 


I initially thought package extensions might be a way to accomplish this, but there are some issues:


  • If customer wants v2, they must install v1 first. This gets worse as new major releases are completed.
  • The DE org(s) for major releases after v1 would each create a new namespace prefix.
It looks like a Patch Organizization (ch. 8 of Developing Packages for Distribution) would be the best tool for this problem. Can anyone with some experience with Patch Orgs confirm this? Any additional advice or opinions are welcome and appreciated.



Patch orgs are the way to go.  Log a case in the partner portal to get this feature enabled for you.  

CyberGroup Inc.CyberGroup Inc.

There are a number of limitations with Patch org. (Stated Below)



Development in a patch development organization is restricted. The following is a list of caveats when developing patches in a patch development organization:
• New package components can't be added.
• Existing package components can't be deleted.
• API and dynamic Apex access controls can't change for the package.
• No deprecation of Apex, objects, or fields.
• No new Apex class relationships, such as extends, can be added.
• No new Apex access modifiers, such as virtual or global, can be added.
• No new Web services can be added.


The way I would suggest is: Create Multiple Orgs.



  1.  Developement Org. - Trunk (For Continuous Development) Do not move the code to release org until you want to do a major release V2 (For intermediate testing you can create managed beta packages and test on some other orgs)

  2.  Release Org.  - Branch - Move the code to this org whenever you want to a major release (For immidiate bug fixing and minor changes as it will always have the lastest released code) - Merge back to trunk after the minor release

  3.  Release Test Org. - For testing the Managed Release Package

  4.  For every release create a Tag in SVN with version number so that you have the release specific code.