Skip to content

Commit

Permalink
Catch up with current procedures
Browse files Browse the repository at this point in the history 
- Git is used for moving existing extensions to PECL
- PHP versions with the PHP 7.4 examples
- Some minor tweaks here and there
- Mention re2c also
- Mention Docker image as a helper tool
  • Loading branch information
@petk
petk committed Jul 8, 2019
1 parent 5017676 commit d094ca8
Showing 1 changed file with 58 additions and 45 deletions.
103 changes: 58 additions & 45 deletions docs/release-process.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -37,34 +37,43 @@

Moving extensions from php-src to PECL:

* Checkout the pecl directory, most likely you want a sparse-root checkout
* Ask someone with Git admin access to create a new empty repository on
https://git.php.net under the PECL projects and a belonging GitHub mirror.

```
svn co --depth=empty https://svn.php.net/repository/pecl
* Clone a new copy of the php-src repository (it will rewrite history, keep
contributors commits and include only the extension folder):

```sh
git clone https://git.php.net/repository/php-src.git ext-name
cd ext-name
git filter-branch --prune-empty --subdirectory-filter ext/ext-name master
```

* Create a directory for the extension including branch and tag structure,
no trunk at this point and commit this to svn
* Set remote Git push URL for the PECL extension:

```
cd pecl; mkdir foo foo/tags foo/branches; svn add foo; svn commit
```
```sh
git remote set-url origin [email protected]:pecl/category/ext-name
```

* Move the extension from php-src to the new location
* Create branch and tags structure appropriate for the extension and push:

```
svn mv https://svn.php.net/repository/php/php-src/trunk/ext/foo \
https://svn.php.net/repository/pecl/foo/trunk
```
```sh
git push -u origin master
```

If the extension is still usable or not dead, in cooperation with the
extension maintainers if any:

* Create the pecl.php.net/foo package and its content, license, maintainer
* Create the package.xml, commit
* Release the package

For moving extensions from PECL to php-src the svn mv has to be done the
other way round.
For moving extensions from PECL to php-src the procedure needs to go through
the RFC process and a new Git commit without rewriting the php-src Git
commit history.

8. There is a PHP release Docker image https://github.com/sgolemon/php-release
with forks available to help releasing.

## Rolling a non stable release (alpha/beta/RC)

Expand All @@ -76,42 +85,43 @@
3. Run the `scripts/dev/credits` script in php-src and commit the changes in
the credits files in ext/standard.

4. Checkout the release branch for this release (e.g., PHP-5.4.2) from the main
4. Checkout the release branch for this release (e.g., PHP-7.4.2) from the main
branch.

5. Bump the version numbers in `main/php_version.h`, `Zend/zend.h`,
`configure.ac` and possibly `NEWS`. Do not use abbreviations for alpha and
beta. Do not use dashes, you should `#define PHP_VERSION "5.4.22RC1"` and
not `#define PHP_VERSION "5.4.22-RC1"`
beta. Do not use dashes, you should `#define PHP_VERSION "7.4.22RC1"` and
not `#define PHP_VERSION "7.4.22-RC1"`

6. Compile and run `make test`, with and without ZTS, using the right Bison
version (for example, for PHP 7.4, minimum Bison 3.0.0 is used).
6. Compile and run `make test`, with and without ZTS, using the right Bison and
re2c version (for PHP 7.4, minimum Bison 3.0.0 and re2c 0.13.4 are used).

7. Check `./sapi/cli/php -v` output for version matching.

8. If all is right, commit the changes to the release branch:

```
```sh
git commit -a
```

9. Tag the repository release branch with the version, e.g.:

```
git tag -u YOURKEYID php-5.4.2RC2
```sh
git tag -u YOURKEYID php-7.4.2RC2
```

10. Bump the version numbers in `main/php_version.h`, `Zend/zend.h`,
`configure.ac` and `NEWS` in the *main* branch (PHP-5.4 for example) to
prepare for the **next** version. F.e. if the RC is "5.4.1RC1" then the new
one should be `5.4.2-dev` - regardless if we get a new RC or not. This is to
`configure.ac` and `NEWS` in the *main* branch (PHP-7.4 for example) to
prepare for the **next** version. F.e. if the RC is "7.4.1RC1" then the new
one should be `7.4.2-dev` - regardless if we get a new RC or not. This is to
make sure `version_compare()` can correctly work. Commit the changes to the
main branch.
11. Push the changes to the main repo, the tag, the main branch and the release
branch:
branch. Release branches for alpha/beta/.0RCx releases before to GA release
don't need to be pushed (a local temporary branch should be used).
```
```sh
git push --tags origin HEAD
git push origin {main branch}
git push origin {release branch}
Expand Down Expand Up @@ -139,15 +149,16 @@
1. Update `qa.git/include/release-qa.php` with the appropriate information. See
the documentation within release-qa.php for more information, but all
releases and RCs are configured here. Only $QA_RELEASES needs to be edited.
releases and RCs are configured here. Only `$QA_RELEASES` needs to be
edited.
Example: When rolling an RC, set the 'rc' with appropriate information for
Example: When rolling an RC, set the `rc` with appropriate information for
the given version.
Note: Remember to update the sha256 checksum information.
2. Skip this step for non stable releases after GA of minor or major versions
(e.g. announce 7.3.0RC1, but not 7.3.1RC1):
(e.g. announce 7.4.0RC1, but not 7.4.1RC1):
Add a short notice to phpweb stating that there is a new release, and
highlight the major important things (security fixes) and when it is
Expand All @@ -159,9 +170,9 @@
* Add the content for the news entry. Be sure to include the text:
```
"THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!"
```
```text
"THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!"
```
3. Commit and push changes to qa and web.
Expand All @@ -181,7 +192,7 @@
setup as a moderator for `[email protected]` by having someone
(Hannes, Dan, Derick) run the following commands for you:
```
```sh
ssh lists.php.net
sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address
```
Expand All @@ -194,7 +205,7 @@
2. If a CVE commit needs to be merged to the release, then have it committed to
the base branches and merged upwards as usual (f.e commit the CVE fix to
5.3, merge to 5.4, 5.5 etc...). Then you can cherry-pick it in your release
7.2, merge to 7.3, 7.4 etc...). Then you can cherry-pick it in your release
branch. Don't forget to update `NEWS` manually in an extra commit then.
3. Commit those changes. Ensure the tests at
Expand All @@ -203,8 +214,8 @@
4. Run the `scripts/dev/credits` script in php-src and commit the changes in
the credits files in ext/standard.
5. Compile and make test, with and without ZTS, using the right Bison version
(for example, for PHP 7.4, minimum Bison 3.0.0 is used).
5. Compile and run `make test`, with and without ZTS, using the right Bison and
re2c version (for PHP 7.4, minimum Bison 3.0.0 and re2c 0.13.4 are used).
6. Check `./sapi/cli/php -v` output for version matching.
Expand All @@ -229,7 +240,7 @@
`web/php-distributions.git`, then update the git submodule reference in
`web/php.git`:
```
```sh
git submodule init
git submodule update
cd distributions
Expand All @@ -252,8 +263,8 @@
1. Update `phpweb/include/releases.inc` with the old release info (updates the
download archives).
* You can run `php bin/bumpRelease 7 2` where the first number is the major
version, and the second number is the minor version (7.2 in this example).
* You can run `php bin/bumpRelease 7 4` where the first number is the major
version, and the second number is the minor version (7.4 in this example).
* If that fails for any non-trivially fixable reason, you can manually copy
the old information to `include/releases.inc`.
Expand All @@ -263,12 +274,12 @@
* `$PHP_X_Y_VERSION` to the correct version
* `$PHP_X_Y_DATE` to the release date
* `$PHP_X_Y_SHA256` array and update all the SHA256 sums
* `$PHP_X_Y_TAGS` array should include 'security' if this is a security
* `$PHP_X_Y_TAGS` array should include `security` if this is a security
release
* Make sure there are no outdated "notes" or edited "date" keys in the
`$RELEASES[X][$PHP_X_VERSION]["source"]` array.
3. Create the release file (releases/x_y_z.php)
3. Create the release file (`releases/x_y_z.php`)
Usually we use the same content as for point 6, but included in php template
instead of the release xml.
Expand Down Expand Up @@ -308,7 +319,7 @@
8. **Check website has been synced before announcing or pushing news**
Try, f.e. https://www.php.net/distributions/php-7.3.4.tar.xz
Try, f.e. https://www.php.net/distributions/php-7.4.0.tar.xz
Website may update slowly (may take an hour).
Expand Down Expand Up @@ -428,4 +439,6 @@
5. Request moderation access to [email protected] and
[email protected] lists, to be able to moderate your release
announcements. All the announcements should be sent from the @php.net alias.
announcements. All the announcements should ideally be sent from the
@php.net alias. Note, that for sending emails as @php.net alias a custom
SMTP server needs to be used.

0 comments on commit d094ca8

Please sign in to comment.