README.RELEASE_PROCESS: misleading branching info?

Hej *All*, We from tigermedia support team would kindly ask if it is possible to have the email fb@tigermedia.dk removed from the PHP internals list as the mail is no longer in use. And every mail is fowarded to our support. We have tried to remove it from the list our selves, but we don't have the required credentials to login to the associated account :) We apologize in advance to all the list members that are not related to this issue. We didn't know how else to proceed :( Med venlig hilsen / Kind regards [image: uc?id=0Bxs12uFOzYYKZE5jSmtxWTBMX0U&export=download] *Glen S. Jensen* *Softwareudvikler* Telefon: +45 96 500 300 | Email: gsj@tigermedia.dk Tiger Media A/S | Systemvej 12 | 9200 AAlborg SV <https://maps.google.com/?q=Systemvej+12+%7C+9200+Aalborg+SV&entry=gmail&source=g> | Web: www.tigermedia.dk For supportspørgsmål kontakt os da på support@tigermedia.dk eller på tlf. 96 500 300 og din henvendelse vil blive besvaret af første ledige medarbejder. 2018-06-05 12:37 GMT+02:00 Christoph M. Becker <cmbecker69@gmx.de>:

Hi Christoph, On Tue, 2018-06-05 at 12:37 +0200, Christoph M. Becker wrote:

You can always use a release branch as an intermediate place to prepare a release, it's only about your way of work and situation. For example you could fork the release from the today's latest master, but want to revert one revision. Or, you could fork the release branch from a particular revision, not the latest. You can reset that PHP-x.y.z branch at any point or apply some extra patches to it, as you own it. Usually there is a release branch, where everything like versions, news and so on gets prepared and from which a tag is created then.

PHP-x.y is a development branch. When it is branched off, it gets integrated into the git workflow and the regular fixes need to be merged there. Till then, master is used as a dev branch so it needs to be semi blocked for huge changes, features not planned for 7.3 would have to hold on. It's again at RMs consideration, whether the dev to be forked earlier or later. The approximation to create a dev branch before beta is given, because in the alpha phase some is per se unstable. Beta is usually the feature freeze, no new features should flow in. Until the PHP-x.y branch is created, there are less branches to merge, so that's the advantage of creating it at a later point. Perhaps we need more clearance in that doc yet. Please lets check, if you have any suggestions so we can formalize the process better. Regards Anatol

On Tue, Jun 5, 2018 at 6:37 AM, Christoph M. Becker <cmbecker69@gmx.de> wrote:

"the main branch" is quite misleading, I agree. It should perhaps be something like: 4a. If this is an alpha release, checkout the master branch. 4b. If this is a beta release, checkout the previously forked development branch (e.g. PHP-7.3) 4c. For RC releases, checkout a release branch (e.g. PHP-7.2.0) cut from the appropriate maintenance branch (e.g. PHP-7.2) if required.

Indeed it is. The timetable I wrote up prior to the RM selection also notes this: https://wiki.php.net/todo/php73 -Sara