Lines Matching refs:release
3 A release manager's role includes making packaged source code from the canonical
4 repository available according to the release schedule.
6 The release schedule for each version is published on the
17 PHP on the fourth Thursday of November each year. Following the GA release, we
18 publish patch-level releases every four weeks, with at least one release
19 candidate (RC) published two weeks before each patch-level release.
21 Each major and minor version undergoes a 24-week pre-release cycle before GA
22 release. The pre-release cycle begins on the second Thursday of June with the
23 first alpha release of the new major/minor version. The pre-release cycle
28 - 6 release candidates
30 Feature freeze for the next major/minor occurs with the first beta release.
38 New release managers should review [New release manager
39 checklist](#new-release-manager-checklist) at the end of this document. This
46 1. Do not release on Fridays, Saturdays, or Sundays as this gives poor lead
49 Our general procedure is to release on Thursdays, whenever possible.
51 2. Package two days before a release.
53 If the release is to be on Thursday, package on Tuesday. Think about
83 6. There is a PHP release Docker image https://github.com/sgolemon/php-release
86 7. Communicate with release managers via release-managers@php.net.
101 ## Packaging a non-stable release (alpha/beta/RC)
103 All releases during the pre-release cycle (alpha/beta/RC) leading up to the GA
104 release for a version are *non-stable* releases. Following the GA release, all
120 3. Check out the *release branch* for this release from the *version branch*.
124 > main branch as the version branch. You will create a local-only release
128 > git checkout -b php-X.Y.0alpha1-local-release-branch upstream/master
131 > During the first RC release, you will create (and push!) the version
132 > branch for the pre-GA release, e.g., `PHP-8.2`. See
134 > From this point forward, all pre-GA release branches will be created from
135 > this version branch. Again, these release branches are local-only. Do not
139 > git checkout -b php-X.Y.0beta2-local-release-branch upstream/PHP-X.Y
144 > along with each non-stable release. For example, if you are building a
145 > release for PHP 8.2.8 RC1, you will create the `PHP-8.2.8` patch-level
157 > local-only release branch. Do not push this one!
160 > git checkout -b php-X.Y.ZRC1-local-release-branch upstream/PHP-X.Y.Z
163 4. Using your local-only release branch, bump the version numbers in
192 > When releasing the *first release candidate* of a pre-GA release, you must
228 versions match the release.
230 7. If all is correct, commit the changes to your local-only release branch.
237 8. Tag your local-only release branch with the release version.
244 your release (e.g., `PHP-8.2`) and bump the version numbers in
268 > Only release tags should have version numbers in these files that do not
283 > Local-only release branches should not be pushed!
285 11. Run the following using the release tag to export the tree, create the
293 12. Run the following using the release tag and your GPG key ID to sign the
324 16. Once the release is tagged, contact the release-managers@ distribution
328 Here is an example "ready for builds" message to release-managers@php.net:
346 ## Announcing a non-stable release (alpha/beta/RC)
349 information in the `$QA_RELEASES` array in `include/release-qa.php`.
351 Follow the documentation in the file for editing the QA release information.
363 there is a new release, and highlight the major changes (e.g., security
376 # 1: New PHP release [releases]
394 text slightly to indicate progression through the pre-release cycle. For
430 In the announcement message, point out the location of the release and the
431 possible release date of either the next RC or the final release. Also
435 Here are a few examples of non-stable release announcement emails:
452 > release.
455 Derick) to post a tweet with the RC release announcement and link to the news
459 ## Packaging a stable release
461 1. Check out the *patch-level version branch* for the release
465 > You should have created this branch when packaging the non-stable release
468 2. If a CVE commit needs to be merged to the release, have it committed to
471 patch-level version branch for this release.
488 4. Create a local-only release branch for this release from the *patch-level
492 git checkout -b php-X.Y.Z-local-release-branch upstream/PHP-X.Y.Z
495 5. Using your local-only release branch, bump the version numbers in
501 `8.1.8-dev`. In your local-only release branch, you will change them all to
532 versions match the release.
534 8. If all is correct, commit the changes to your local-only release branch.
541 9. Tag your local-only release branch with the release version and push the tag.
548 10. Run the following using the release tag to export the tree, create the
566 11. Run the following using the release tag and your GPG key ID to sign the
619 15. Once the release is tagged, contact the release-managers@ distribution
626 Here is an example "ready for builds" message to release-managers@php.net:
644 ## Announcing a stable release
647 previous release to `include/releases.inc`.
650 previous release is 8.2.1, so you will add the information for 8.2.1 to this
658 version. In this example, we're bumping the release information for version
663 > for the previous release from `include/version.inc` into
666 2. Update the version information for the new release in `include/version.inc`.
672 * Set `date` to the release date in `j M Y` format (e.g. '5 Jan 2021')
673 * Update the `tags` array to include `'security'` if this is a security release
674 * Update the `sha256` array with the hashes for each of the release tarballs
676 3. Create the release file and news entry for the new version.
682 This will create a release file (i.e., `releases/X_Y_Z.php`) and a news entry
707 information in the `$QA_RELEASES` array in `include/release-qa.php`.
710 in preparation for the current release. Since the current release is now GA,
713 It is sufficient to set the `number` property for the release to `0` to
736 * Is there a release page for the new version?
744 included in the release mail.
754 changelog. Here are a few examples of stable release announcement emails:
761 > For standard patch-level releases, we will note "This is a bugfix release."
762 > If it is a security release, we must note "This is a security release."
771 the release announcement and link to the news entry on php.net.
777 While unlikely, there may be times we need to re-release the same version. This
780 Should this occur *before* announcing the release, you may choose to delete the
787 If this happens *after* announcing the release, you may choose to tag, package,
788 and release a patch-level (i.e., *pl*) release. If it is not critical and/or
790 next release.
792 If you choose to create a patch-level release, follow these steps:
797 (X.Y=major.minor release, e.g. '8.0'):
800 * `date` to the release date in `j M Y` format (e.g. '9 Jan 2021')
801 * `tags` array should include `security` if this is a security release
804 3. Add a short notice to `web-php` stating that there is a new release, and
826 A major/minor version [feature freeze][] occurs with the first beta release.
827 Specifically, it occurs when the first beta release is packaged, which means the
828 feature freeze occurs two days before the first beta release.
839 As a courtesy to the community, the release managers should remind others about
887 > We create the new version branch at the first release candidate rather than at
896 1. When you release the first pre-GA RC, remind the documentation team
899 link to it in the release announcements.
902 release.
906 sections for each pre-release.
909 ## Prime the selection of release managers for the next version
911 About three months prior to the scheduled release of the first alpha release of
913 release managers for the latest version branch should issue a call for
914 volunteers to begin the selection process for the next release managers.
920 should aim to select the release managers by early April, so announcing the
925 release manager (having previously served as a `php-src` release manager),
929 3. Help the new release managers with their first steps.
932 ## New release manager checklist
935 added to the release-managers@ distribution list.
937 2. Request membership to the release managers group on GitHub.
970 the release managers listed in `php-keyring.gpg`. Then, you will export,
971 specifying your key ID in addition to the key IDs of every other release
986 git commit --gpg-sign=YOURKEYID -m "Update PHP release manager keyring"
992 release announcements. All the announcements should be sent from your
