Publishing extensions from a bundle
This page is for bundlers whose bundle contains extensions that others could use. The partner's checklist is Publishing an extension as a partner; this page follows it and adds what a bundler should consider.
Contents
Which extensions to publish
| Extension in your bundle | Publish? |
|---|---|
| A generic feature (an operator, a datatype, an integration) | yes, it helps others and gets you fixes from them |
| Bundle glue (your installer hooks, your branding) | usually no; keep it in the bundle's repository |
| Customer-specific code | no, unless the customer agrees and you remove everything customer-specific |
| A fork of someone else's extension | send changes upstream first (Contributing extensions back) |
The steps
From Publishing an extension as a partner:
- Separate it from the customer project: no customer names, URLs, credentials, content or business rules; customer-specific behavior becomes a setting with a neutral default.
- Metadata:
ezinfo.phpwith'Version'(novprefix), name, copyright, license and info URL;extension.xmlwith the same<version>,<license>and<info_url>;composer.jsonif you publish on Packagist;php -l ezinfo.phpandxmllint --noout extension.xmlpass. - License and notices: a
LICENSEfile; "for code built on Exponential, a GPL-compatible license (the project uses GPL v2 or later)"; third-party code listed with its license. - README: what it does, requirements, install, activate, configure, support, license.
- Repository and package: a public Git repository, issues enabled, registered on Packagist "with the webhook so new tags appear".
- Release (below).
- Announce it: forum post, project page.
Name it with your own prefix, never exp (Naming and branding a bundle).
Releases that never move
- "Choose the version from the published tags, sorted by version (
git tag -l 'v*' --sort=version:refname)." - "Commit the version bump first, then tag that commit."
- "Never move or delete a published tag; publish the next version instead."
Packagist reads a tag once; a moved tag gives two different packages with one version number. Your bundle then pins the published version like any other (Versions, tags and pinning).
After publishing
- Require the published package in your bundle instead of a private copy.
- "Test it against each new Exponential release"; "Answer issues; merge useful pull requests"; "When you stop maintaining it, say so in the README."
- Log it with the partner team if you are a partner (Logging your partner activity).
Related pages
- Extension bundles
- Extensions (developer guide)
- Extension and theme partners
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.