Dileep Burki - 5 years ago
In Spring'15, we are doing a limited pilot of a new feature "Branch Orgs." It enables the creation of multiple developer edition orgs with the same namespace, helping in team development. It does NOT solve many issues discussed in this thread like multiple namespaces in the same org, but is a step in helping in team development.
Adam Perrell - 5 years ago
Aside from the technical implications, this problem also relates to corporate branding. I would like the namespace to represent my corporate brand. The current setup, which requires separate namespaces for each package forces the namespace to be product brand associated. I assume partners selling multiple apps are using some type of corporate/product combination for their namespaces? This would be similar to iPhone, where 'i' is the corporate and 'phone' is to product.
Leon Vet - 6 years ago
This is a sorely missed feature. We like the patch orgs and use them to provide small hotfixes but what we could really use is a 'feature org'.
Like the patch org this would also create a sandbox on the managed package dev org but allows the same type of changes you can now perform in the package dev org itself. Each new feature we want to add to our product would go into such a feature sandbox, making parallel development and solid release management possible. Namespace issues are no longer there because the dev org's namespace would also be assigned to all feature sandboxes. Merging all changes back into the dev org could be provided by salesforce or through a decent setup of your own version control system.
Luke Kozakewycz - 6 years ago
I think this needs a much more defined approach. Such approach could include building a system whereby you have the central packaging org where the namespace is held. Through the packaging org, we should be able to create our developer orgs with the same namespace and a slightly altered username by default.
We need something that works very much like the creation of patch organizations!
PcCare Support - 7 years ago
I am amazed that this is the case. It seems so odd to me that you can't have more than one managed package. I can see some reasons why you would want it that way, for instance updating 1 package could brake another, but that is the way apex classes and triggers and other things are and they have the testing feature built into it so that it doesn't happen.
Jeremy Weber - 7 years ago
I think both of these option would be beneficial to the SF dev community.
If #2 was implemented we would no longer have to manage and maintain the klunky approach of namespace replacement in code in order to support multiple developers on the same project.
#1 is a no brainer - how can one create common componentry when everything is uber-sandboxed.
Kartik Viswanadha - 7 years ago
This would be a lot helpful when doing a parallel development. We are having this issue in our company where we want to do parallel development in two different orgs on top of same code base, but since we are working in 2 orgs the namespaces would be different. This is painful for Integrating Systems.
Scott Sanders - 8 years ago
This gets worse if you have shared data model. If you have a free version of a package, and a paid premium for instance, you will force your customers to data migrate due to the namespace issue.
If you have several apps that interact across each other, you are forced to add another 'comon data model' package that is now a prerequisite to the install process.