Re: [PHP-DEV] Better types without runtime checking

[Ryan Jentzsch]

Why would something like this not work?

strict class MyClass
{
protected int $foo = 1;
public string $bar = "strict keyword in front of class allows/enforces
strict properties";
private string $isItReallyThatDifficult = "to implement this?";
}

On Tue, Jun 5, 2018 at 4:17 PM, Rowan Collins 
wrote:

> On 05/06/2018 08:22, Rudolph Gottesheim wrote:
>
>> There's always a lot of talk about types in the PHP community.
>> Specifically, many developers want property types, generics, function
>> signature types, union and intersection types, and more. Those talks (and
>> RFCs) always end with the same result: "We can't do it because performance
>> issues."
>>
>> Has there ever been a discussion about adding some of those features
>> syntactically, but ignoring them during runtime? At least until someone
>> finds a performant way to check them at runtime. That way we could have
>> advanced type checking in our editors at least.
>>
>
>
> Hi,
>
> I believe this is part of the original aim of Hack-Lang: the additional
> type features of that language are not part of the run-time, but checked by
> a static analysis tool offline. A number of languages have similar setups -
> Python and Dart both have the types as offline and/or development-mode-only
> features. Indeed, PHP seems to have gone a very unusual route in having a
> dynamic language with type constraints which are effectively always-on
> assertions.
>
> One of the problems with moving PHP to this offline-checking model is that
> people will expect new type constraints to work like existing ones, so may
> be caught out by them not being checked at run-time. Worse, static checks
> may not be able to detect certain violations; I don't know much about
> Hack's model, but I understand it includes both different levels of
> strictness, and restrictions on dynamic language features - things like
> references, "variable variables", and non-object callables.
>
> I do think it's an interesting question to think about though.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP 7.3 timetable

[Sara Golemon]

On Tue, Jun 5, 2018 at 6:44 PM, Christoph M. Becker  wrote:
> I've pushed the fingerprint of my GPG key to web-php[1], and also made
> it available on pgp.mit.edu[2].  As I understand it, this should be
> sufficient to sign it.  Otherwise, please tell me what to do.
>
Looks good:

$ gpg --recv-keys 'CBAF 69F1 73A0 FEA4 B537  F470 D66C 9593 118B CCB6'
gpg: key D66C9593118BCCB6: public key "Christoph M. Becker
" imported
gpg: Total number processed: 1
gpg:   imported: 1


However, a certain other 7.3 RM (not naming names), should probably
add his key to the 7.3 section of php.net/gpg-keys
IME, the people who are most hawkishly checking our signatures care
about who's expected to sign a given release. (This is why I'm also
listed under 7.1 RMs)
I can commit a copy from elsewhere in the file, but it should probably
be done by the person who's key it is. :D

> As far as I know, I'm not yet subscribed to the “release managers list”,
> and I have no experience with IRC.  If necessary, I can catch up on
> this, but it'll take some time.
>
Make sure systems@ is poked about that.  You really do need to be on
the distribution list.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Sara Golemon]

On Tue, Jun 5, 2018 at 5:41 PM, Christoph M. Becker  wrote:
> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.3 timetable

[Stanislav Malyshev]

Hi!

> I've pushed the fingerprint of my GPG key to web-php[1], and also made
> it available on pgp.mit.edu[2].  As I understand it, this should be
> sufficient to sign it.  Otherwise, please tell me what to do.

Should be enough to start signing packages, I assume.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.3 timetable

[Christoph M. Becker]

On 05.06.2018 at 19:53, Anatol Belski wrote:

> I haven't seen the tag pushed yet. The signing process is otherwise
> described in the doc. You can use any service to excercise before
> pushing to the git.php.net, fe github. Usually pgp.mit.edu is used to
> publish keys. If you've already published the GPG key you're intended
> to use, please send it so we can sign.

I've pushed the fingerprint of my GPG key to web-php[1], and also made
it available on pgp.mit.edu[2].  As I understand it, this should be
sufficient to sign it.  Otherwise, please tell me what to do.

> In further it would be ok to
> discuss on the release managers list, also you could ping on IRC if
> there's more.

As far as I know, I'm not yet subscribed to the “release managers list”,
and I have no experience with IRC.  If necessary, I can catch up on
this, but it'll take some time.

> Aller Anfang ist schwer, aber schaffbar :)

Thanks!  I'm quite confident about this. :)

[1]

[2] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Better types without runtime checking

[Rowan Collins]

On 05/06/2018 08:22, Rudolph Gottesheim wrote:
There's always a lot of talk about types in the PHP community. 
Specifically, many developers want property types, generics, function 
signature types, union and intersection types, and more. Those talks 
(and RFCs) always end with the same result: "We can't do it because 
performance issues."


Has there ever been a discussion about adding some of those features 
syntactically, but ignoring them during runtime? At least until 
someone finds a performant way to check them at runtime. That way we 
could have advanced type checking in our editors at least.



Hi,

I believe this is part of the original aim of Hack-Lang: the additional 
type features of that language are not part of the run-time, but checked 
by a static analysis tool offline. A number of languages have similar 
setups - Python and Dart both have the types as offline and/or 
development-mode-only features. Indeed, PHP seems to have gone a very 
unusual route in having a dynamic language with type constraints which 
are effectively always-on assertions.


One of the problems with moving PHP to this offline-checking model is 
that people will expect new type constraints to work like existing ones, 
so may be caught out by them not being checked at run-time. Worse, 
static checks may not be able to detect certain violations; I don't know 
much about Hack's model, but I understand it includes both different 
levels of strictness, and restrictions on dynamic language features - 
things like references, "variable variables", and non-object callables.


I do think it's an interesting question to think about though.

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.3 timetable

[Christoph M. Becker]

On 05.06.2018 at 20:55, Stanislav Malyshev wrote:

>> Due to some pending preliminary work, I won't be able to release
>> 7.3.0alpha1 on Thursday.  Unless Stas is willing to tackle the first
>> alpha, I suggest to postpone the tentative timetable[1] by a week.  I
>> don't think that would be a problem, since 7.0 - 7.2 had their first
>> alphas released on the second Thursday of June as well.
> 
> Ah, it's that time already. I could try to build it (haven't done it for
> a while, so my setup could be a little rusty) and see if it works by
> Thursday, then I'll publish it. If not, then we can take a week delay,
> it's not a huge deal.

Thanks, Stas!  I shall catch up with my pending issues soon.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Christoph M. Becker]

On 05.06.2018 at 18:22, Sara Golemon wrote:

> On Tue, Jun 5, 2018 at 6:37 AM, Christoph M. Becker  wrote:
>
>> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RM karma

[Sara Golemon]

On Tue, Jun 5, 2018 at 5:14 PM, Christoph M. Becker  wrote:
> Thanks to both of you!  In the meantime Martin and Rasmus already set up
> the directory on downloads for me; I'll still have to manage the
> google-authenticator stuff, though.
>
I'll take the blame for not holding the RM selection sooner.
Honestly, it should have been done in March/April timeframe in order
to leave time for setup like this.

Sorry,
-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RM karma

[Christoph M. Becker]

On 05.06.2018 at 21:02, Sara Golemon wrote:

> On Tue, Jun 5, 2018 at 2:38 PM, Stanislav Malyshev  
> wrote:
>
>> Don't know about the downloads, unfortunately, but I think you should
>> have the full commit karma, at least from my reading of the karma file.
>>
>> I can definitely put the binaries into my directory on downloads, at
>> least for now. Can't help much with the lists though (except for sending
>> the mails when needed of course).
>
> I poked Derick to create the accounts needed and indeed I can see a
> cmb home directory on downloads.  So he should be able to just create
> ~/public_html and drop the tarballs in place assuming he's able to
> navigate the maze to get there.  If posting to QA list becomes an
> issue, several of us can pick up that one thing, so we should be
> relatively good to go.

Thanks to both of you!  In the meantime Martin and Rasmus already set up
the directory on downloads for me; I'll still have to manage the
google-authenticator stuff, though.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Better types without runtime checking

[Dan Ackroyd]

> Has there ever been a discussion about adding some of those features
> syntactically, but ignoring them during runtime? At least until someone
> finds a performant way to check them at runtime. That way we could have
> advanced type checking in our editors at least.

You can have that today: https://preprocess.io/

The main thing that would missing would be a mapping of source file +
line to the running code, which would make debugging harder.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RM karma

[Sara Golemon]

On Tue, Jun 5, 2018 at 2:38 PM, Stanislav Malyshev  wrote:
> Don't know about the downloads, unfortunately, but I think you should
> have the full commit karma, at least from my reading of the karma file.
>
> I can definitely put the binaries into my directory on downloads, at
> least for now. Can't help much with the lists though (except for sending
> the mails when needed of course).
>
I poked Derick to create the accounts needed and indeed I can see a
cmb home directory on downloads.  So he should be able to just create
~/public_html and drop the tarballs in place assuming he's able to
navigate the maze to get there.  If posting to QA list becomes an
issue, several of us can pick up that one thing, so we should be
relatively good to go.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.3 timetable

[Stanislav Malyshev]

Hi!

> Due to some pending preliminary work, I won't be able to release
> 7.3.0alpha1 on Thursday.  Unless Stas is willing to tackle the first
> alpha, I suggest to postpone the tentative timetable[1] by a week.  I
> don't think that would be a problem, since 7.0 - 7.2 had their first
> alphas released on the second Thursday of June as well.

Ah, it's that time already. I could try to build it (haven't done it for
a while, so my setup could be a little rusty) and see if it works by
Thursday, then I'll publish it. If not, then we can take a week delay,
it's not a huge deal.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RM karma

[Stanislav Malyshev]

Hi!

Don't know about the downloads, unfortunately, but I think you should
have the full commit karma, at least from my reading of the karma file.

I can definitely put the binaries into my directory on downloads, at
least for now. Can't help much with the lists though (except for sending
the mails when needed of course).

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.3 timetable

[Anatol Belski]

On Tue, 2018-06-05 at 19:14 +0200, Christoph M. Becker wrote:
> On 05.06.2018 at 17:10, Sara Golemon wrote:
> 
> > On Tue, Jun 5, 2018 at 10:26 AM, Anatol Belski  wrote:
> > 
> > > On Tue, 2018-06-05 at 15:36 +0200, Christoph M. Becker wrote:
> > > 
> > > > Due to some pending preliminary work, I won't be able to
> > > > release
> > > > 7.3.0alpha1 on Thursday.  Unless Stas is willing to tackle the
> > > > first
> > > > alpha, I suggest to postpone the tentative timetable[1] by a
> > > > week.  I
> > > > don't think that would be a problem, since 7.0 - 7.2 had their
> > > > first
> > > > alphas released on the second Thursday of June as well.
> > 
> > On the one hand: Timetables can be pushed, we're not curing cancer
> > here.
> > On the other, that's what a second RM is for, so let's see what
> > Stas has to say.
> 
> ACK.
> 
> > > By the pending work, do you mean the yet missing karma, etc. you
> > > mentioned in another thread? If so - actually you still could
> > > tag,
> > > write site news, etc. - so most of the things. With the items
> > > where
> > > there is no karma yet like uploading to downloads.php.net or
> > > mailing a
> > > moderated list could be helped.
> > 
> > Indeed. Joe had key issues recently and due to not having his new
> > key
> > in place in time we pushed the tarballs out of band, but they still
> > had his sigs and all the rest.  A rough start, sure.  But alphas
> > are a
> > great time to make and learn from mistakes. :D
> 
> That's indeed one of the issues.  After quite some struggle, I've
> just
> managed to sign a tag with a quickly generated GPG key.  However, I
> still need to create a proper GPG (including generating a revocation
> certificate), and of course, the key has to be signed by one or more
> of
> the previous RMs (not sure how that will work).
> 
I haven't seen the tag pushed yet. The signing process is otherwise
described in the doc. You can use any service to excercise before
pushing to the git.php.net, fe github. Usually pgp.mit.edu is used to
publish keys. If you've already published the GPG key you're intended
to use, please send it so we can sign. In further it would be ok to
discuss on the release managers list, also you could ping on IRC if
there's more.

Aller Anfang ist schwer, aber schaffbar :)  

Regards

Anatol

Re: [PHP-DEV] PHP 7.3 timetable

[Christoph M. Becker]

On 05.06.2018 at 17:10, Sara Golemon wrote:

> On Tue, Jun 5, 2018 at 10:26 AM, Anatol Belski  wrote:
>
>> On Tue, 2018-06-05 at 15:36 +0200, Christoph M. Becker wrote:
>>
>>> Due to some pending preliminary work, I won't be able to release
>>> 7.3.0alpha1 on Thursday.  Unless Stas is willing to tackle the first
>>> alpha, I suggest to postpone the tentative timetable[1] by a week.  I
>>> don't think that would be a problem, since 7.0 - 7.2 had their first
>>> alphas released on the second Thursday of June as well.
>
> On the one hand: Timetables can be pushed, we're not curing cancer here.
> On the other, that's what a second RM is for, so let's see what Stas has to 
> say.

ACK.

>> By the pending work, do you mean the yet missing karma, etc. you
>> mentioned in another thread? If so - actually you still could tag,
>> write site news, etc. - so most of the things. With the items where
>> there is no karma yet like uploading to downloads.php.net or mailing a
>> moderated list could be helped.
>
> Indeed. Joe had key issues recently and due to not having his new key
> in place in time we pushed the tarballs out of band, but they still
> had his sigs and all the rest.  A rough start, sure.  But alphas are a
> great time to make and learn from mistakes. :D

That's indeed one of the issues.  After quite some struggle, I've just
managed to sign a tag with a quickly generated GPG key.  However, I
still need to create a proper GPG (including generating a revocation
certificate), and of course, the key has to be signed by one or more of
the previous RMs (not sure how that will work).

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Sara Golemon]

On Tue, Jun 5, 2018 at 6:37 AM, Christoph M. Becker  wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Better types without runtime checking

[Michael Morris]

On Tue, Jun 5, 2018 at 2:22 AM Rudolph Gottesheim 
wrote:

> There's always a lot of talk about types in the PHP community.
> Specifically, many developers want property types, generics, function
> signature types, union and intersection types, and more. Those talks
> (and RFCs) always end with the same result: "We can't do it because
> performance issues."
>
> Has there ever been a discussion about adding some of those features
> syntactically, but ignoring them during runtime? At least until someone
> finds a performant way to check them at runtime. That way we could have
> advanced type checking in our editors at least.
>
> The idea will sound familiar to TypeScript users. It works great for
> that language.
>

It's an interesting compromise, but I worry about the confusion it may sow,
particularly for incoming programmers from languages that do enforce such
things - such as Java.

Re: [PHP-DEV] PHP 7.3 timetable

[Sara Golemon]

On Tue, Jun 5, 2018 at 10:26 AM, Anatol Belski  wrote:
> On Tue, 2018-06-05 at 15:36 +0200, Christoph M. Becker wrote:
>> Due to some pending preliminary work, I won't be able to release
>> 7.3.0alpha1 on Thursday.  Unless Stas is willing to tackle the first
>> alpha, I suggest to postpone the tentative timetable[1] by a week.  I
>> don't think that would be a problem, since 7.0 - 7.2 had their first
>> alphas released on the second Thursday of June as well.
>>
>
On the one hand: Timetables can be pushed, we're not curing cancer here.
On the other, that's what a second RM is for, so let's see what Stas has to say.

> By the pending work, do you mean the yet missing karma, etc. you
> mentioned in another thread? If so - actually you still could tag,
> write site news, etc. - so most of the things. With the items where
> there is no karma yet like uploading to downloads.php.net or mailing a
> moderated list could be helped.
>
Indeed. Joe had key issues recently and due to not having his new key
in place in time we pushed the tarballs out of band, but they still
had his sigs and all the rest.  A rough start, sure.  But alphas are a
great time to make and learn from mistakes. :D

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Better types without runtime checking

[Theodore Brown]

One Tue, Jun 5, 2018 at 2:28 AM Yasuo Ohgaki  wrote:

> On Tue, Jun 5, 2018 at 4:23 PM Rudolph Gottesheim 
> wrote:
>
>> There's always a lot of talk about types in the PHP community.
>> Specifically, many developers want property types, generics, function
>> signature types, union and intersection types, and more. Those talks
>> (and RFCs) always end with the same result: "We can't do it because
>> performance issues."
>>
>> Has there ever been a discussion about adding some of those features
>> syntactically, but ignoring them during runtime? At least until someone
>> finds a performant way to check them at runtime. That way we could have
>> advanced type checking in our editors at least.
>>
>> The idea will sound familiar to TypeScript users. It works great for
>> that language.
>>
>> I'm excited to hear your opinions.
>
> DbC style has no performance issue at all. In addition, you can perform
> much better validation than simple type checks.
>
> function f($username) {
>   assert(is_string($username) && preg_match('\\A[a-z]\\z', $username);
>   
> }

Assertions are not a replacement for syntactical type declarations, since
they cannot be checked until runtime. They are also more verbose, and
don't help editors provide autocompletion when writing code.

+1 to the possibility of a PHP static type checker which can be run
independently from the runtime to support more advanced types without
degrading performance.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.3 timetable

[Anatol Belski]

On Tue, 2018-06-05 at 15:36 +0200, Christoph M. Becker wrote:
> Hi!
> 
> Due to some pending preliminary work, I won't be able to release
> 7.3.0alpha1 on Thursday.  Unless Stas is willing to tackle the first
> alpha, I suggest to postpone the tentative timetable[1] by a week.  I
> don't think that would be a problem, since 7.0 - 7.2 had their first
> alphas released on the second Thursday of June as well.
> 
By the pending work, do you mean the yet missing karma, etc. you
mentioned in another thread? If so - actually you still could tag,
write site news, etc. - so most of the things. With the items where
there is no karma yet like uploading to downloads.php.net or mailing a
moderated list could be helped.


Regards

Anatol 

Re: [PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Anatol Belski]

Hi Remi,

On Tue, 2018-06-05 at 14:44 +0200, Remi Collet wrote:
> 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

[PHP-DEV] PHP 7.3 timetable

[Christoph M. Becker]

Hi!

Due to some pending preliminary work, I won't be able to release
7.3.0alpha1 on Thursday.  Unless Stas is willing to tackle the first
alpha, I suggest to postpone the tentative timetable[1] by a week.  I
don't think that would be a problem, since 7.0 - 7.2 had their first
alphas released on the second Thursday of June as well.

Any objections?

[1] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Remi Collet]

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




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Anatol Belski]

Hi Christoph,

On Tue, 2018-06-05 at 12:37 +0200, Christoph M. Becker wrote:
> 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].
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

Re: [PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Glen S. Jensen]

Hej *All*,

 We from tigermedia support team would kindly ask if it is possible to have
the email f...@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: g...@tigermedia.dk

Tiger Media A/S | Systemvej 12 | 9200 AAlborg SV

|
Web: www.tigermedia.dk

For supportspørgsmål kontakt os da på supp...@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 :

> 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] 
> [2]  >
> [3] 
> [4]
>  RELEASE_PROCESS#L338-L341>
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] README.RELEASE_PROCESS: misleading branching info?

[Christoph M. Becker]

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] 
[2] 
[3] 
[4]


-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: RM karma

[Christoph M. Becker]

Hi!

Since I didn't receive any response to my request, and apparently
 has not yet been set up, I wonder if
there is something wrong with my request.  Did I send it to the wrong
address?  Is something else wrong?

Please tell me, if you need further information.  Otherwise please
implement my request as soon as possible.

Thanks!

On 29.05.2018 at 22:25, Christoph M. Becker wrote:

> Ping
> 
> On 14.05.2018 at 23:00, Christoph M. Becker wrote:
> 
>> Hi!
>>
>> Since I (c...@php.net) am one of the release managers of PHP 7.3,
>> according to
>>  I
>> request:
>>
>>   * to get setup for access to downloads.php.net and to be added to the
>> release-managers@ distribution list
>>
>>   * karma to edit main/php_version.h
>>
>>   * moderation access to annou...@php.net and
>> primary-qa-tes...@lists.php.net lists
>>
>> Thanks in advance.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: undocumented session_name() change

[Yasuo Ohgaki]

On Sun, May 27, 2018 at 1:16 AM Christoph M. Becker 
wrote:

> On 25.05.2018 at 12:28, Christoph M. Becker wrote:
>
> >   if ($_GET['action'] == 'newsession') {
> >$session_name = getNewSessionName();  // user-defined function
> >session_name($session_name);
> >session_regenerate_id();
> >header('Location: ' ….);  // restart script to use new session name
> > and id
> >exit;
> >   }
> >
> > Why even call session_name($session_name) here?  To my knowledge, this
> > is a no-op in this case (assuming a session has already been started).
>
> I have to correct myself.  Actually, the call to session_regenerate_id()
> did change the session name (i.e. the cookie etc.)  I'm still not
> convinced, that this BC break should be reverted.
>

Session module uses a few INI settings to work. As we know, INI values are
stored in modules global structure.

Since session works uses INI values as "Parameters" for module and its
submodules
while it is active, modifying these INI values caused number of unwanted
misbehaviors/crashes. i.e. It's side effect of changing globals.

These INI values must not be changed in the first place, but session module
didn't have proper internal state management. Since these side effects won't
be problem unless users abuse/misuse them, it was left until 7.2.

7.2 protects module globals (PS(session_name) is one of them) to prevent
abuse/misuse. Any function calls that cause side effects raise ERROR as
described in UPGRADING.

Since 7.2 prohibits harmful calls, users protected from some of very
hard to debug problems, e.g.
 - Works in a environment, but not in other
 - Works mostly, but fails sometimes

Even when users are affected by this change, there are ways to write code
that work in any PHP versions.

session_name('new_name') can be called while session is inactive in this
case. i.e. session_commit(); session_name('new_name'); session_start();

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Better types without runtime checking

[Yasuo Ohgaki]

On Tue, Jun 5, 2018 at 4:23 PM Rudolph Gottesheim 
wrote:

> There's always a lot of talk about types in the PHP community.
> Specifically, many developers want property types, generics, function
> signature types, union and intersection types, and more. Those talks
> (and RFCs) always end with the same result: "We can't do it because
> performance issues."
>
> Has there ever been a discussion about adding some of those features
> syntactically, but ignoring them during runtime? At least until someone
> finds a performant way to check them at runtime. That way we could have
> advanced type checking in our editors at least.
>
> The idea will sound familiar to TypeScript users. It works great for
> that language.
>
> I'm excited to hear your opinions.
>

DbC style has no performance issue at all. In addition, you can perform
much better validation than simple type checks.

function f($username) {
  assert(is_string($username) && preg_match('\\A[a-z]\\z', $username);
  
}

--
Yasuo Ohgaki
yohg...@ohgaki.net

[PHP-DEV] Better types without runtime checking

[Rudolph Gottesheim]

There's always a lot of talk about types in the PHP community. 
Specifically, many developers want property types, generics, function 
signature types, union and intersection types, and more. Those talks 
(and RFCs) always end with the same result: "We can't do it because 
performance issues."


Has there ever been a discussion about adding some of those features 
syntactically, but ignoring them during runtime? At least until someone 
finds a performant way to check them at runtime. That way we could have 
advanced type checking in our editors at least.


The idea will sound familiar to TypeScript users. It works great for 
that language.


I'm excited to hear your opinions.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php