Managed package install

Question

I recently realized that we cannot install a managed package beta in a customer environment. We need to provide our package to a customer and that leaves us with an option of converting the managed package to a release package . I had the following questions before we convert our package to release :

1. What are the repercussions of moving from managed beta to managed release ?

2. What components get frozen once you make this move ?

3. Can you remove custom objects / fields from a release package in subsequent versions

4. Are there gotchas that we need to be aware of ?

5. If we submit a security review of this release package at 1.1 and the customer site is at say 1.4 , how would we merge these changes ?

Answer 1

What are the repercussions of moving from managed beta to managed release ?

The restrictions depend on what you're talking about. For example, objects and fields can't be renamed, fields can't change data types, global classes can't be renamed, and so on. Specifics for each type of data are mentioned in Components Available in Managed Packages.

What components get frozen once you make this move ?

Again, the effects are listed in the documentation. Many elements can not be deleted by subscribers (but a few can), more types can be deleted by developers, and many types can not be deleted at all.

Can you remove custom objects / fields from a release package in subsequent versions

Yes. Once deletion is enabled, you can delete any custom fields or objects that you want. To enable deletion, follow the documentation in Deleting Components in Managed Packages.

Are there gotchas that we need to be aware of ?

The main thing is that once you delete a class, trigger, page, component, field, object, workflow rule, validation rule, etc, you can no longer create a new element of the same type with the same name. The names become permanently and irrevocably frozen, which can create all sorts of problems if you're not careful with names.

If we submit a security review of this release package at 1.1 and the customer site is at say 1.4 , how would we merge these changes ?

Once a particular version has been approved, future versions for the next year are automatically also approved through security review. As long as you're passing the annual review with the latest version, you don't have to get every new version reviewed.

Answer 2

Here are your answers:

• What are the repercussions of moving from managed beta to managed release ?
  => Dont worry too much. We can always create another version of release if you missout somehting or something fail.
• What components get frozen once you make this move ?
  => All the the cusomization and configration get lockdown. To make any change we need to create new minor or major version of package
• Can you remove custom objects / fields from a release package in subsequent versions
  => you can deprecate components from new versions of managed package but old versions can not be changed.
• Are there gotchas that we need to be aware of ?
  => Dont rember any such caviate but you can always post another question with specic problem you face.
• If we submit a security review of this release package at 1.1 and the customer site is at say 1.4 , how would we merge these changes ? => your question is not very clear but let me try to give some possible answers.
  => We should not change the code after submitting it for security review. => Although you can create another branch (using any version control) and create another dev org to continue working on our app. Once review team is done we can deploy new code to packing org and create new version. Security review team may do another round of review but its their discretion whether to let you go without check or do complete review again.