Before you create a managed package

Before creating managed packages, here are a few things to consider:

1. You must use a Developer Edition organization to create and work with a managed package. A Developer Edition organization can contain a single managed package and many unmanaged packages.

2. Before converting an unmanaged package to managed, enable your organization to create managed packages. Please review  Creating Managed Packages.

3. You can offer beta versions of a managed package to a small sampling of your users if you are still developing the components within the package but want to allow beta testers to install it and provide feedback. Subscribers of managed packages are not able to downgrade to earlier versions.

4. When you release a managed package, meaning it is uploaded without the Beta checkbox selected, the properties of its components change to prevent developers and subscribers from making harmful changes. If you do not want to offer upgrades to your package, consider keeping it unmanaged.

5. Some components in a released managed package are always editable.

6. The components in a managed package behave differently than those in an unmanaged package at different points in the release process. For example, a subscriber cannot change certain properties of managed components in any package that is in a Managed - Installed state, regardless of whether it is beta. Likewise, the developer cannot change certain properties of managed components in any package that is in a Managed - Released state. However, Managed - Beta components have the same properties as unmanaged components in the developer's organization. Developers should determine when the right time is to make a beta package Managed - Released because doing so restricts the properties of each component within it. Components in a managed packaged have one of the following properties:
 

a. Editable but not upgradeable: This means that components are editable in both the developer's and subscriber's organization. Editable components are not upgradeable. Salesforce remembers which editable components an subscriber has deleted so that it does not reinstall unwanted components. For example, the subscriber can delete a document that was included in a managed package and upgrades to that package that still include the document will not get installed again. Any changes the subscriber makes are also not overwritten during upgrades. Likewise, the publisher can make changes to documents and even delete them but that does not affect the installed users. Each subscriber can have different versions of these items because new subscribers get the component with the latest attributes but previous subscribers do not get their version of the component updated.

b. Restricted in the subscriber's and publisher's organization: A restricted component may have some attributes that are editable in the subscriber's organization but other attributes that are editable in the publisher's organization.

c. Locked in both the developer's and subscriber's organization: This ensures that the components can be upgraded smoothly.

7. Developers can always add additional components to a managed package regardless of its state with a few exceptions:

a. Once a managed package is Managed - Released, the developer can make changes to the profile settings but subscribers will not get these changes when upgrading. We recommend contacting subscribers to ask them to make important profile changes manually when they upgrade.

b. Developers can add universally required custom fields to managed packages as long as they have default values.

c. Developers cannot add auto number fields to Managed - Released packages.

8. Unfortunately, once you make a package Managed, there is no way to change the package back to Unmanaged.

See also: 
Reverting a Managed-Released package version back to Beta
Manage Packages 
Component Behavior in Packages