Hi!
README.RELEASE_PROCESS[1] states in the “Rolling a non stable release
(alpha/beta/RC)” section[2]:
| 4. Checkout the release branch for this release (e.g., PHP-5.4.2) from
| the main branch.
However, it seems that the PHP-x.y.z release branch is usually only cut
shortly before GA[3]. Furthermore, the “Forking a new release branch”
section states that the PHP-x.y branch is supposed to be cut shortly
before the first beta release[4].
So what is the proper procedure here?
[1] https://github.com/php/php-src/blob/master/README.RELEASE_PROCESS
[2] https://github.com/php/php-src/blob/master/README.RELEASE_PROCESS#L66
[3] http://news.php.net/php.internals/101084
[4]
https://github.com/php/php-src/blob/master/README.RELEASE_PROCESS#L338-L341
--
Christoph M. Becker
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!
README.RELEASE_PROCESS[1] states in the “Rolling a non stable release
(alpha/beta/RC)” section[2]:| 4. Checkout the release branch for this release (e.g., PHP-5.4.2) from
| the main branch.However, it seems that the PHP-x.y.z release branch is usually only cut
shortly before GA[3]. Furthermore, the “Forking a new release branch”
section states that the PHP-x.y branch is supposed to be cut shortly
before the first beta release[4].So what is the proper procedure here?
[1] https://github.com/php/php-src/blob/master/README.RELEASE_PROCESS
[2] <https://github.com/php/php-src/blob/master/README.RELEASE_PROCESS#L66[3] http://news.php.net/php.internals/101084
[4]
<https://github.com/php/php-src/blob/master/README.
RELEASE_PROCESS#L338-L341>--
Christoph M. Becker
Hi Christoph,
Hi!
README.RELEASE_PROCESS[1] states in the “Rolling a non stable release
(alpha/beta/RC)” section[2]:
- Checkout the release branch for this release (e.g., PHP-5.4.2)
from
the main branch.However, it seems that the PHP-x.y.z release branch is usually only
cut
shortly before GA[3].
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.
Furthermore, the “Forking a new release branch”
section states that the PHP-x.y branch is supposed to be cut shortly
before the first beta release[4].
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
Le 05/06/2018 à 13:05, Anatol Belski a écrit :
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.
For memory
PHP-7.2 was branched in July 2017 for beta1
PHP-7.1 was branched in July 2016 for beta1
Remi
Hi Remi,
Le 05/06/2018 à 13:05, Anatol Belski a écrit :
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.For memory
PHP-7.2 was branched in July 2017 for beta1
PHP-7.1 was branched in July 2016 for beta1
yeah, seems to be a good precedent to follow.
Regards
Anatol
Hi!
README.RELEASE_PROCESS[1] states in the “Rolling a non stable release
(alpha/beta/RC)” section[2]:| 4. Checkout the release branch for this release (e.g., PHP-5.4.2) from
| the main branch.
"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.
However, it seems that the PHP-x.y.z release branch is usually only cut
shortly before GA[3]. Furthermore, the “Forking a new release branch”
section states that the PHP-x.y branch is supposed to be cut shortly
before the first beta release[4].
Indeed it is. The timetable I wrote up prior to the RM selection also
notes this: https://wiki.php.net/todo/php73
-Sara
README.RELEASE_PROCESS[1] states in the “Rolling a non stable release
(alpha/beta/RC)” section[2]:| 4. Checkout the release branch for this release (e.g., PHP-5.4.2) from
| the main branch."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.
Thanks, that sounds plausible. Some of the following items would need
adjustment as well, for instance, “8. If all is right, commit the
changes to the release branch with git commit -a
.”
If nobody beats me to it, I shall improve README.RELEASE_PROCESS in this
regard during the next few releases.
--
Christoph M. Becker
If nobody beats me to it, I shall improve README.RELEASE_PROCESS in this
regard during the next few releases.
I would say that you, as the newest RM, are the most qualified to fix
what's out-of-date/missing/wrong. If you put something wrong in, then
be sure to fix it when you realize your mistake. I did a bit of that
last year. :D
-Sara