Answers.Body: <p>There are several places which rely on the full name of the extension:</p>
  
  <ul>
  <li><em>Extension directory</em>: One must create a new record for the new extension key. Ownership, release-history, etc, will be different.</li>
  <li><em>Pingback stats</em>: The old and new name will have separate stats.</li>
  <li><em>Upgrades (downloading new code)</em>: Upgrades issued in the new name won't be displayed as upgrades on existing installations (which expect the old name).</li>
  <li><em>Upgrades (tracking/updating DB schema)</em>: The schema versions of the extensions are separate.</li>
  <li><em>Managed entities</em>: If the old and new extensions insert managed entities, there could be uniqueness conflicts. (The ManagedEntities manager does <em>not</em> impose a global uniqueness constraint, but some specific entities do enforce uniqueness -- eg you can't simultaneously register two payment-processor-types with the same name.)</li>
  </ul>
  
  <p>My recommendation: Don't think of it as renaming an extension; think of it as publishing a new extension (and reusing code from the old extension). The new extension should be designed around the old one (eg using different names throughout and/or migrating data).</p>
  
  <p>Speaking in the abstract without a specific extension, it's not simple to rename or replace a extension. However, for specific extensions, there may be mitigating factors:</p>
  
  <ul>
  <li><em>(No) DB content</em>: If the extension only adds runtime functionality (via hooks) and does not insert anything into the DB, then it will be easier to rename/replace. If the extension does insert into the DB (eg via hook_install, via Upgrader, or via managed-entities), then expect some tasks or complications.</li>
  <li><em>Private vs public extension</em>: If the extension wasn't released to the public, then you may be able to hack through conflicts (eg manually changing over DB references), and you probably won't care about the extensions directory, the pingback stats, or distributing upgrades.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-09T03:53:09.990Z
Answers.LastActivityDate: 2015-06-09T03:53:09.990Z
Answers.UserDisplayName: Tim Otten
Body: <p>Say we have an extension with short-name "fancywidget" which is managed by Company A. The full name of the extension is <code>com.a.fancywidget</code>.</p>
  
  <p>Now say Company A drops maintenance of it, and Company B steps up to take over. It's still the "fancywidget" extension, but under new ownership.</p>
  
  <p>Is it safe to rename the extension to <code>com.b.fancywidget</code>? What are the implications (e.g. for the extension directory, pingback stats, etc.) of doing so?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-09T04:18:59.450Z
Comments.Text: Since both com.a.fancywidget and com.b.fancywidget will have namespace conflicts (hook function names), what reasons are there for developers to use the com.X prefix?
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-09T09:55:55.807Z
Comments.Text: I've asked the same question. One response is that it's technically possible to avoid a conflict by setting a different `<file>` tag in each `info.xml`, although that kicks the can down the road. (Which module should change its `<file>`? Who identifies the conflicts?) Another response is that the long name gives some branding. Personally, I'd be +1 on deprecating long-names (eg require a standard prefix, "org.civicrm.", for all new extensions), but this might be a better conversation for the developer forum.
Comments.UserDisplayName: Tim Otten
Tags: <extension>
Title: How to transfer ownership of an extension
ThreadText: # How to transfer ownership of an extension
  
  (Asked by: username_0 on 2015-06-07)
  
  Say we have an extension with short-name "fancywidget" which is managed by Company A. The full name of the extension is `com.a.fancywidget`.
  
  Now say Company A drops maintenance of it, and Company B steps up to take over. It's still the "fancywidget" extension, but under new ownership.
  
  Is it safe to rename the extension to `com.b.fancywidget`? What are the implications (e.g. for the extension directory, pingback stats, etc.) of doing so?
  
  **Tags:** extension
  
  > **Comments:**
  > **username_1**: Since both com.a.fancywidget and com.b.fancywidget will have namespace conflicts (hook function names), what reasons are there for developers to use the com.X prefix?  
  > **username_2**: I've asked the same question. One response is that it's technically possible to avoid a conflict by setting a different `<file>` tag in each `info.xml`, although that kicks the can down the road. (Which module should change its `<file>`? Who identifies the conflicts?) Another response is that the long name gives some branding. Personally, I'd be +1 on deprecating long-names (eg require a standard prefix, "org.civicrm.", for all new extensions), but this might be a better conversation for the developer forum.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2015-06-09. Score: 6 | Accepted answer
  
  There are several places which rely on the full name of the extension:
  
  * *Extension directory*: One must create a new record for the new extension key. Ownership, release-history, etc, will be different.
  * *Pingback stats*: The old and new name will have separate stats.
  * *Upgrades (downloading new code)*: Upgrades issued in the new name won't be displayed as upgrades on existing installations (which expect the old name).
  * *Upgrades (tracking/updating DB schema)*: The schema versions of the extensions are separate.
  * *Managed entities*: If the old and new extensions insert managed entities, there could be uniqueness conflicts. (The ManagedEntities manager does *not* impose a global uniqueness constraint, but some specific entities do enforce uniqueness -- eg you can't simultaneously register two payment-processor-types with the same name.)
  
  My recommendation: Don't think of it as renaming an extension; think of it as publishing a new extension (and reusing code from the old extension). The new extension should be designed around the old one (eg using different names throughout and/or migrating data).
  
  Speaking in the abstract without a specific extension, it's not simple to rename or replace a extension. However, for specific extensions, there may be mitigating factors:
  
  * *(No) DB content*: If the extension only adds runtime functionality (via hooks) and does not insert anything into the DB, then it will be easier to rename/replace. If the extension does insert into the DB (eg via hook\_install, via Upgrader, or via managed-entities), then expect some tasks or complications.
  * *Private vs public extension*: If the extension wasn't released to the public, then you may be able to hack through conflicts (eg manually changing over DB references), and you probably won't care about the extensions directory, the pingback stats, or distributing upgrades.
  
  
  ---
  
  