Are you looking for information on the process handling abandoned extensions for CiviCRM? See [Abandoned Extensions](#abandoned-extensions).
...
...
@@ -14,7 +14,7 @@ Of course, this collaboration means that we're all engaged in some give-and-take
-**Consumers**: Sometimes we're the receivers. We want to quickly browse the available extensions, pick the ones which look best, and install them. We expect the extensions to work — both now and going forward (with future upgrades).
-**Developers**: Sometimes we're the providers. We enjoy building great functionality, and want to invite people to use our products, but need to juggle the publishing tasks (like testing and maintenance releases) with the goals and resources provided by our bosses and clients.
With the extension life-cycle described here, we seek to build an ecosystem that balances the needs of both consumers and developers.
With the extension lifecycle described here, we seek to build an ecosystem that balances the needs of both consumers and developers.
@@ -22,9 +22,10 @@ CiviCRM's publishing process automates a number of tasks related to maintaining
- The extension code is published on CiviCRM's Gitlab or on a public GitHub repository.
- The extension manifest (`info.xml`) is in the root of the repository.
- The extension manifest is [valid](info-xml.md#ExtensionReference-Tagsininfo.xml).
- Each release of the extension has a git tag with a ["PHP-standardized" version number string](http://php.net/manual/en/function.version-compare.php). Version number strings may optionally be prefixed with a "v".
- Valid tag names: "v1.2.3", "1.2.3"
- Invalid (ignored) tag names: "stable", "1.2-prerelease", "1.2-beta"
- Each release of the extension has a git tag using a ["semantic version number string](https://semver.org/) such as "1.2.3" (major.minor.patch). The recommended practice is to increment the:
- major version when you make breaking changes,
- minor version when you add functionality in a backward compatible manner,
- patch version when you make backward compatible bug fixes.
You can tag alpha/beta releases, but they will not be listed in the directory. We assume that the objective of alpha/beta releases is for advanced users running a test environment. It would be confusing for regular administrators to see weekly alpha/beta releases of the extension in the CiviCRM extension directory, or to be notified in-app about a new beta upgrade available.
...
...
@@ -44,8 +45,8 @@ Extensions added to civicrm.org automatically create a Gitlab project on [CiviCR
* Create a git "tag" which matches the version in the manifest and push it, e.g.:
```
git tag -a v1.2.0
git push origin v1.2.0
git tag -a 1.2.0
git push origin 1.2.0
```
* Now to get that release on CiviCRM.org:
...
...
@@ -80,10 +81,12 @@ It is strongly recommended that you [write unit tests](https://github.com/civicr
Once an extension release meets these criteria, the extension will be approved for automated distribution by a CiviCRM community extension moderator.
For more information, see the [Extension Lifecycle](../lifecycle/).
## Translation
When an extension is approved for automatic distribution, it will automatically be added to Transifex under the [civicrm_extensions](https://www.transifex.com/civicrm/civicrm_extensions/) project so that any strings in the interface (if there are any) may be translated.
This synchronisation task is run nightly. It also generates the translation files, which may be downloaded with the [l10nupdate](https://github.com/cividesk/com.cividesk.l10n.update) extension or by guessing the URL using the form:
This synchronisation task is run nightly. It also generates the translation files, which may be downloaded with the [Update Language Files](https://civicrm.org/extensions/update-language-files) extension or by guessing the URL using the form:
