pecl:releasing-a-pecl-package

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
pecl:releasing-a-pecl-package [2019/10/31 11:20] – Make sure you're polite :) asgrimpecl:releasing-a-pecl-package [2019/10/31 12:35] (current) – Win builds may take some hours cmb
Line 3: Line 3:
 This set of tips is intended for people who would like to submit a PHP module or Zend extension that they have written into the PECL repository (for example, so end users can use ''pecl install yourextension''). This set of tips is intended for people who would like to submit a PHP module or Zend extension that they have written into the PECL repository (for example, so end users can use ''pecl install yourextension'').
  
-  * Write your package first, with a suite of ''.phpt'' tests+  * Write your package first, with a suite of ''.phpt'' tests in the ''tests'' directory.
   * Pick a name for your package   * Pick a name for your package
-  * Ensure it is licensed correctly (PHP License, MIT, BSD, Apache etc. are all acceptable)+  * Ensure it is licensed correctly (PHP License, MIT, BSD, Apache etc. are all acceptable, but GPL or LGPL are not)
   * Join the pecl-dev mailing list - https://pecl.php.net/support.php#lists   * Join the pecl-dev mailing list - https://pecl.php.net/support.php#lists
-  * Apply for an account - https://pecl.php.net/account-request.php+  * Apply for a PECL account under your own name (don't use a 'team name') - https://pecl.php.net/account-request.php
     * Ideally reach out to #php.pecl on EFnet IRC first, or email the pecl-dev list - e.g. ("hi folks, I'd like to release X on PECL...")     * Ideally reach out to #php.pecl on EFnet IRC first, or email the pecl-dev list - e.g. ("hi folks, I'd like to release X on PECL...")
     * Introduce yourself, explain what your package does, why it does it, who will support it etc.     * Introduce yourself, explain what your package does, why it does it, who will support it etc.
     * "Need a php.net account?" - only tick this if you want to put docs on php.net docs eventually     * "Need a php.net account?" - only tick this if you want to put docs on php.net docs eventually
     * Once account request sent, follow up in #php.pecl on EFnet, so your account can be approved - there are a lot of "invalid" account requests, so its worth politely reaching out to make sure your request is not forgotten     * Once account request sent, follow up in #php.pecl on EFnet, so your account can be approved - there are a lot of "invalid" account requests, so its worth politely reaching out to make sure your request is not forgotten
-  * Use strict gcc flags - https://github.com/xdebug/xdebug/blob/master/config.m4#L36-L75+  * Use strict GCC flags - https://github.com/xdebug/xdebug/blob/master/config.m4#L36-L75
   * Version constant in ''php_extname.h'' should be called ''PHP_EXTNAME_VERSION'', e.g. ''PHP_MYGREATEXT_VERSION'' (PECL uploader checks this matches ''package.xml'' version)   * Version constant in ''php_extname.h'' should be called ''PHP_EXTNAME_VERSION'', e.g. ''PHP_MYGREATEXT_VERSION'' (PECL uploader checks this matches ''package.xml'' version)
   * Create a ''package.xml'' - copy & edit from another package (from git/vcs repo, not a "release")   * Create a ''package.xml'' - copy & edit from another package (from git/vcs repo, not a "release")
 +    * Make sure that you update the maintainers section with your user, and that your user is only marked as **lead** (and not listed twice).
   * Ensure you have tested at least against ZTS, NTS, for each PHP version you will support (in automated CI pipeline ideally!)   * Ensure you have tested at least against ZTS, NTS, for each PHP version you will support (in automated CI pipeline ideally!)
  
Line 22: Line 23:
   * In ''package.xml''   * In ''package.xml''
     * Copy the current release into a new ''changelog.release'' element     * Copy the current release into a new ''changelog.release'' element
-    * Update the current release section (date/time/version/stability/notes)+    * Update the current release section: date, time, version, stability (alpha, beta, stable), and notes
     * ''pecl package-validate'' to check everything looks good     * ''pecl package-validate'' to check everything looks good
-    * Commit update to ''package.xml'' 
   * Run your tests (e.g. in CI)   * Run your tests (e.g. in CI)
-  * Recommended to create a tag in your VCS (e.g. ''git tag -s <version>'') 
   * Use ''pecl package'' to generate a release ''.tgz'' file   * Use ''pecl package'' to generate a release ''.tgz'' file
 +  * Commit update to ''package.xml''
 +  * Recommended to create a tag in your VCS (e.g. ''git tag -s <version>'') and sign it with a GPG key if you can
   * Login and upload the ''.tgz'' to https://pecl.php.net/release-upload.php   * Login and upload the ''.tgz'' to https://pecl.php.net/release-upload.php
 +
 +For an example of a more comprehensive release process, it might be worth checking out https://github.com/xdebug/xdebug/blob/master/RELEASE_PROCESS.rst
 +
 +==== Windows binary packages ====
 +
 +Windows binary packages (including the DLLs) are supposed to be built and linked on the package page automatically. If that didn't happen several hours after the release, contact the PHP for Windows team via #winphp-dev on freenode IRC or email the pecl-dev list.
pecl/releasing-a-pecl-package.1572520840.txt.gz · Last modified: 2019/10/31 11:20 by asgrim

Page Tools