Lines Matching refs:version
6 The release schedule for each version is published on the
21 Each major and minor version undergoes a 24-week pre-release cycle before GA
23 first alpha release of the new major/minor version. The pre-release cycle
77 > the first few releases of your version. For the steps related to the
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*.
122 > �� **Non-stable version branches: pre-GA** \
123 > There is no *version branch* for alpha or beta releases. Instead, treat the
124 > main branch as the version branch. You will create a local-only release
131 > During the first RC release, you will create (and push!) the version
133 > "[Forking a new version branch](#forking-a-new-version-branch)" below.
135 > this version branch. Again, these release branches are local-only. Do not
142 > �� **Non-stable version branches: post-GA** \
143 > After GA, you will create (and push) a new *patch-level version branch*
146 > version branch from the `PHP-8.2` version branch.
153 > We will use the patch-level version branch to commit any critical bug or
154 > security fixes before this version's GA.
156 > Then, from the patch-level version branch, you will create another
163 4. Using your local-only release branch, bump the version numbers in
191 > �� **API version bump for pre-GA** \
193 > also bump the API version numbers in `Zend/zend_extensions.h`,
237 8. Tag your local-only release branch with the release version.
243 9. �� **For post-GA releases only,** switch back to the *version branch* for
244 your release (e.g., `PHP-8.2`) and bump the version numbers in
246 the version branch for the next version.
248 For example, if the RC is `8.2.1RC1` then the version numbers in the version
253 Commit the changes to the version branch.
261 > Version branches (e.g. `PHP-8.1`) will *always* have version numbers in
263 > Patch-level version branches (e.g. `PHP-8.1.7`) will also *always* have
264 > version numbers that end in `-dev` in these files. The main branch (i.e.
265 > `master`) will *always* have version numbers that end in `-dev` in these
268 > Only release tags should have version numbers in these files that do not
275 git push upstream PHP-X.Y.Z # patch-level version branch (post-GA only)
276 git push upstream PHP-X.Y # version branch
414 > > Please DO NOT use this version in production, it is an early test version.
417 > When a version is in its post-GA phase, we do not post news entries for
460 1. Check out the *patch-level version branch* for the release
465 > candidate for this version.
470 patch-level version branch for this release.
472 Commit these changes and push the patch-level version branch. Ensure
477 > patch-level version branch.
479 3. Run the `./scripts/dev/credits` script in the patch-level version branch,
488 version branch*.
494 5. Using your local-only release branch, bump the version numbers in
498 For example, if you're releasing a stable version for PHP 8.1.8, then all
499 the version numbers in the patch-level version branch should be
540 9. Tag your local-only release branch with the release version and push the tag.
648 For example, if you are preparing to announce version 8.2.2, then the
656 The first number is the major version, and the second number is the minor
657 version. In this example, we're bumping the release information for version
662 > for the previous release from `include/version.inc` into
665 2. Update the version information for the new release in `include/version.inc`.
667 Find the part of the `$data` array that is related to your version (e.g.,
670 * Set `version` to the full version number (e.g. '8.2.1')
675 3. Create the release file and news entry for the new version.
685 Within these files, it will generate standard messages for the new version.
688 4. Update the ChangeLog file for the given major version (e.g., `ChangeLog-8.php`).
730 * Check the "downloads" page to make sure the new version appears:
735 * Is there a release page for the new version?
737 * Does the RC for this version still appear on the QA home page?
774 ## Re-releasing the same version or a patch-level (i.e., `-plN`)
776 While unlikely, there may be times we need to re-release the same version. This
795 2. Update $data['X.Y'] in `web-php:/include/version.inc`
798 * `version` to the full version number (e.g. '8.0.1-pl1')
807 * Call `php bin/createReleaseEntry -v <version> [ --security ]` in your
810 4. Commit all the changes (`include/version.inc`, `archive/archive.xml`,
825 A major/minor version [feature freeze][] occurs with the first beta release.
831 version, they should be discussed and have the voting polls closed no later than
835 Following the feature freeze, the focus of work for the new version will be on
844 ## Forking a new version branch
846 When the new version has reached the first RC, it is time to create a new
847 version branch. This frees up the main branch (i.e., `master`) for any new
848 feature development that cannot go into the new version.
850 1. One week prior to tagging `X.Y.0RC1`, warn internals@ that your version's
854 2. Just prior to tagging `X.Y.0RC1`, create the new version branch locally,
862 * update the version numbers in `configure.ac`, `main/php_version.h`,
864 * update the API version numbers in `Zend/zend_extensions.h`,
871 4. Push the new version branch and the changes to the `master` branch, with an
886 > We create the new version branch at the first release candidate rather than at
888 > version ready for RC and GA. During this time, the main branch is *only* for
893 ## Preparing for the initial stable version (PHP X.Y.0)
897 is available before releasing the initial stable version, since you should
908 ## Prime the selection of release managers for the next version
911 the next minor or major version (around March 1st or shortly thereafter), the
912 release managers for the latest version branch should issue a call for
