[RFC] [DISCUSSION] Deprecate PHP's short open tags V2

  106256
July 23, 2019 17:54 george.banyard@gmail.com ("G. P. B.")
Hello internals,

Due to the controversy after the initial vote on the Deprecate PHP's Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the help
of Nikita Popov <nikic@php.net>.

This RFC is targeting PHP 7.4 and has an exemption to land after the
feature freeze granted by the Release Managers of PHP 7.4 Derick Rethans <
derick@php.net> and Peter Kokot <petk@php.net>, CCed to this email.

https://wiki.php.net/rfc/deprecate_php_short_tags_v2

Discussion is expected to last 2 weeks followed by a 2 week vote such that
this RFC may land in PHP7.4Beta3 as per the timeline. [2]

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Best regards

George P. Banyard

[1] https://wiki.php.net/rfc/deprecate_php_short_tags
[2] https://wiki.php.net/todo/php74
  106257
July 23, 2019 19:09 rowan.collins@gmail.com (Rowan Collins)
On 23 July 2019 18:54:48 BST, "G. P. B." banyard@gmail.com> wrote:
>The only point of contention of this RFC that I potentially see is the >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 >instead of it being removed in PHP 9 after it having had a whole major >version release cycle.
Given that you've already predicted that this will be controversial, could you provide some rationale for it? Unless there's a major burden in maintaining the parser error behaviour for a few years, waiting for the next major version would seem both safer and more in line with official versioning policy. As with deprecation itself, any violation of the "no breaking changes" rule, however slight, should have an explicit justification. If I had a vote, any RFC omitting such a justification would receive an automatic "no" from me. Regards, -- Rowan Collins [IMSoP]
  106265
July 23, 2019 21:03 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins collins@gmail.com>
wrote:

> On 23 July 2019 18:54:48 BST, "G. P. B." banyard@gmail.com> wrote: > >The only point of contention of this RFC that I potentially see is the > >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 > >instead of it being removed in PHP 9 after it having had a whole major > >version release cycle. > > Given that you've already predicted that this will be controversial, could > you provide some rationale for it? Unless there's a major burden in > maintaining the parser error behaviour for a few years, waiting for the > next major version would seem both safer and more in line with official > versioning policy. > > As with deprecation itself, any violation of the "no breaking changes" > rule, however slight, should have an explicit justification. If I had a > vote, any RFC omitting such a justification would receive an automatic "no" > from me. >
I agree. I don't think there's a pressing need to do the "full removal" in PHP 8.1 in particular, so it makes more sense to this in the next major version (9.0), as usual. Nikita
  106266
July 23, 2019 21:10 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I agree. I don't think there's a pressing need to do the "full removal" in > PHP 8.1 in particular, so it makes more sense to this in the next major > version (9.0), as usual.
This may be more acceptable, if we are sure there would be no short tags code remaining anywhere by the time of 9.0. -- Stas Malyshev smalyshev@gmail.com
  106268
July 23, 2019 21:39 petercowburn@gmail.com (Peter Cowburn)
On Tue, 23 Jul 2019 at 22:03, Nikita Popov ppv@gmail.com> wrote:

> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins collins@gmail.com> > wrote: > > > On 23 July 2019 18:54:48 BST, "G. P. B." banyard@gmail.com> > wrote: > > >The only point of contention of this RFC that I potentially see is the > > >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 > > >instead of it being removed in PHP 9 after it having had a whole major > > >version release cycle. > > > > Given that you've already predicted that this will be controversial, > could > > you provide some rationale for it? Unless there's a major burden in > > maintaining the parser error behaviour for a few years, waiting for the > > next major version would seem both safer and more in line with official > > versioning policy. > > > > As with deprecation itself, any violation of the "no breaking changes" > > rule, however slight, should have an explicit justification. If I had a > > vote, any RFC omitting such a justification would receive an automatic > "no" > > from me. > > > > I agree. I don't think there's a pressing need to do the "full removal" in > PHP 8.1 in particular, so it makes more sense to this in the next major > version (9.0), as usual. > > Nikita >
Would you (George, Nikita) consider removing the details about the eventual removal of the feature from this RFC? We can run with the error for a bunch of releases / years, and see what happens. I don't see why we should necessarily decide now on something that might be 5 years or more away.
  106269
July 23, 2019 21:42 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Would you (George, Nikita) consider removing the details about the eventual > removal of the feature from this RFC? We can run with the error for a > bunch of releases / years, and see what happens. I don't see why we should > necessarily decide now on something that might be 5 years or more away.
That sounds like a good idea - nothing prevents us from talking about the removal once we are in the vicinity of 9.0 and have better picture of whether any short tags code is out there or everybody is already enlightened. -- Stas Malyshev smalyshev@gmail.com
  106281
July 24, 2019 12:20 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn <petercowburn@gmail.com>
wrote:

> > > On Tue, 23 Jul 2019 at 22:03, Nikita Popov ppv@gmail.com> wrote: > >> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins collins@gmail.com> >> wrote: >> >> > On 23 July 2019 18:54:48 BST, "G. P. B." banyard@gmail.com> >> wrote: >> > >The only point of contention of this RFC that I potentially see is the >> > >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 >> > >instead of it being removed in PHP 9 after it having had a whole major >> > >version release cycle. >> > >> > Given that you've already predicted that this will be controversial, >> could >> > you provide some rationale for it? Unless there's a major burden in >> > maintaining the parser error behaviour for a few years, waiting for the >> > next major version would seem both safer and more in line with official >> > versioning policy. >> > >> > As with deprecation itself, any violation of the "no breaking changes" >> > rule, however slight, should have an explicit justification. If I had a >> > vote, any RFC omitting such a justification would receive an automatic >> "no" >> > from me. >> > >> >> I agree. I don't think there's a pressing need to do the "full removal" in >> PHP 8.1 in particular, so it makes more sense to this in the next major >> version (9.0), as usual. >> >> Nikita >> > > Would you (George, Nikita) consider removing the details about the > eventual removal of the feature from this RFC? We can run with the error > for a bunch of releases / years, and see what happens. I don't see why we > should necessarily decide now on something that might be 5 years or more > away. >
I don't see a benefit in leaving this open-ended and prefer to have a fixed timeline for this. The full removal in 9.0 is already very, very conservative. Using short tags will have produced a fatal error for a whole major version at that point. If necessary the question can be reevaluated at that time, but the burden of proof must be on the people arguing an additional delay, not the other way around. Nikita
  106288
July 24, 2019 21:40 petercowburn@gmail.com (Peter Cowburn)
On Wed, 24 Jul 2019 at 13:21, Nikita Popov ppv@gmail.com> wrote:

> On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn <petercowburn@gmail.com> > wrote: > >> >> >> On Tue, 23 Jul 2019 at 22:03, Nikita Popov ppv@gmail.com> wrote: >> >>> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins collins@gmail.com> >>> wrote: >>> >>> > On 23 July 2019 18:54:48 BST, "G. P. B." banyard@gmail.com> >>> wrote: >>> > >The only point of contention of this RFC that I potentially see is the >>> > >removal in PHP 8.1 after short open tags being a Parse Error in PHP >>> 8.0 >>> > >instead of it being removed in PHP 9 after it having had a whole major >>> > >version release cycle. >>> > >>> > Given that you've already predicted that this will be controversial, >>> could >>> > you provide some rationale for it? Unless there's a major burden in >>> > maintaining the parser error behaviour for a few years, waiting for the >>> > next major version would seem both safer and more in line with official >>> > versioning policy. >>> > >>> > As with deprecation itself, any violation of the "no breaking changes" >>> > rule, however slight, should have an explicit justification. If I had a >>> > vote, any RFC omitting such a justification would receive an automatic >>> "no" >>> > from me. >>> > >>> >>> I agree. I don't think there's a pressing need to do the "full removal" >>> in >>> PHP 8.1 in particular, so it makes more sense to this in the next major >>> version (9.0), as usual. >>> >>> Nikita >>> >> >> Would you (George, Nikita) consider removing the details about the >> eventual removal of the feature from this RFC? We can run with the error >> for a bunch of releases / years, and see what happens. I don't see why we >> should necessarily decide now on something that might be 5 years or more >> away. >> > > I don't see a benefit in leaving this open-ended and prefer to have a > fixed timeline for this. The full removal in 9.0 is already very, very > conservative. Using short tags will have produced a fatal error for a whole > major version at that point. If necessary the question can be reevaluated > at that time, but the burden of proof must be on the people arguing an > additional delay, not the other way around. >
Hypothetically, it can be re-evaluated sooner, particularly if "everyone" in the PHP ecosystem appears to respond very well once the deprecation and error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be a point being made if/when that discussion comes along. My point is that the removal release/date, in my opinion, is a detail that we don't need to be concerned with right now and it's just adding noise. You disagree, and that's totally okay.
> > Nikita >
  106290
July 25, 2019 11:44 rowan.collins@gmail.com (Rowan Collins)
On Wed, 24 Jul 2019 at 22:40, Peter Cowburn <petercowburn@gmail.com> wrote:

> Hypothetically, it can be re-evaluated sooner, particularly if "everyone" > in the PHP ecosystem appears to respond very well once the deprecation and > error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be > a point being made if/when that discussion comes along. My point is that > the removal release/date, in my opinion, is a detail that we don't need to > be concerned with right now and it's just adding noise. You disagree, and > that's totally okay. >
Regardless of when we have the conversation, I will remain opposed to removing it any time before 9.0. There's very little justification for removing it in the first place, so I can't imagine what justification there'd be to remove it 2 or 3 years earlier. The only advantage I can see of delaying the debate is to leave open the possibility of keeping the error into 10.0. If that becomes necessary, it will be a sign that something has gone wrong, because it will imply that takeup of 8.x was so low that people are still running code where this syntax is used. Sadly, given the current zeal for removing working features, I fear that may happen. Regards, -- Rowan Collins [IMSoP]
  106258
July 23, 2019 20:22 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Due to the controversy after the initial vote on the Deprecate PHP's Short > Open Tag RFC [1] here is a new RFC to deprecate them written with the help > of Nikita Popov <nikic@php.net>.
Could you please explain what has changed since the last time we discussed it that makes it necessary to bring the second RFC on the same topic? Did any arguments about the dangers of removing the short tags somehow became invalid? If yes, then how? What necessitates changing the results of that RFC almost immediately after it was implemented? In the RFC, I read: Worse than that, code using short open tags deployed on a server using short_open_tag=0 will leak application code, because short open tags are silently ignored. I am not sure how it is supposed to be an argument for making such behavior the default. Could you explain? -- Stas Malyshev smalyshev@gmail.com
  106261
July 23, 2019 20:44 rowan.collins@gmail.com (Rowan Collins)
On 23/07/2019 21:22, Stanislav Malyshev wrote:
> Worse than that, code using short open tags deployed on a server using > short_open_tag=0 will leak application code, because short open tags are > silently ignored.
That's precisely what this RFC is intended to prevent. By deprecating *and simply removing* the functionality, as implied by the previous RFC and initially implemented [https://github.com/php/php-src/pull/3975/], we would make such code immediately visible in PHP 8.0. This RFC removes that danger by amending the 8.0 behaviour to *explicitly detecting the tags* and throwing a ParseError.
> I am not sure how it is supposed to be an argument for making such > behavior the default.
This RFC does not make anything the default that is not already; instead, it keeps the INI option as it was before, but changes its behaviour: * In 7.4, the first use of "
  106262
July 23, 2019 20:52 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> That's precisely what this RFC is intended to prevent.
This RFC does nothing to eliminate code written for short-tags - it is impossible to eliminate with any RFC, in fact, it is impossible to eliminate at all. So the only question is what is happening when server is encountering such code.
> immediately visible in PHP 8.0. This RFC removes that danger by amending > the 8.0 behaviour to *explicitly detecting the tags* and throwing a > ParseError.
But only for 8.0. So if you have a bad luck of skipping .0 and going directly for .1 you're still in the same trouble. -- Stas Malyshev smalyshev@gmail.com
  106267
July 23, 2019 21:33 rowan.collins@gmail.com (Rowan Collins)
On 23/07/2019 21:52, Stanislav Malyshev wrote:
> This RFC does nothing to eliminate code written for short-tags - it is > impossible to eliminate with any RFC, in fact, it is impossible to > eliminate at all.
It does more to eliminate it than the previous RFC, by having at least one version where it generates an error, rather than being silently ignored.
> So the only question is what is happening when server > is encountering such code.
Yes, which is exactly what this RFC is changing, because although the previous RFC was accepted, concerns were raised that the details hadn't been fully considered.
>> immediately visible in PHP 8.0. This RFC removes that danger by amending >> the 8.0 behaviour to *explicitly detecting the tags* and throwing a >> ParseError. > But only for 8.0. So if you have a bad luck of skipping .0 and going > directly for .1 you're still in the same trouble.
Yes, as I said elsewhere, I think 9.0 is a much better time for the full removal, and I hope the RFC will be amended appropriately. However, to reiterate, either is still later than the previous RFC. Regards, -- Rowan Collins [IMSoP]
  106263
July 23, 2019 20:56 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Jul 23, 2019 at 10:22 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi! > > > Due to the controversy after the initial vote on the Deprecate PHP's > Short > > Open Tag RFC [1] here is a new RFC to deprecate them written with the > help > > of Nikita Popov <nikic@php.net>. > > Could you please explain what has changed since the last time we > discussed it that makes it necessary to bring the second RFC on the same > topic? Did any arguments about the dangers of removing the short tags > somehow became invalid? If yes, then how? What necessitates changing the > results of that RFC almost immediately after it was implemented?
Sorry, but ... what? I feel like there must be some miscommunication here. This RFC is intended as a courtesy, because the previous one was **accepted**, but quite a few concerns were raised afterward and Zeev has suggested that the question should be reevaluated in a new RFC. This is it. I did not want to just merge the original (accepted!) implementation after the controversial discussion it triggered, but after reading this, I realize that I just wasted my time here. So much for being nice and giving people a fair change to reevaluate the proposal in light of the new arguments that have been brought forward. I guess that next time I'll just go ahead and merge things. Regards, Nikita
  106264
July 23, 2019 20:58 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I did not want to just merge the original (accepted!) implementation > after the controversial discussion it triggered, but after reading this, > I realize that I just wasted my time here. So much for being nice and > giving people a fair change to reevaluate the proposal in light of the > new arguments that have been brought forward. I guess that next time > I'll just go ahead and merge things.
I think nicer would be to explain why we need second RFC and what it adds to the previous one. If I didn't get some context, please explain. -- Stas Malyshev smalyshev@gmail.com
  106273
July 24, 2019 00:37 markyr@gmail.com (Mark Randall)
On 23/07/2019 21:58, Stanislav Malyshev wrote:
> I think nicer would be to explain why we need second RFC and what it > adds to the previous one. If I didn't get some context, please explain.
The previous one, as written, carried a high probability of silently leaking both code and data, but these arguments against it only gained prominence after the RFC had already passed. V2 remedies that by maintaining default INI behaviour, as well as nullifying the possibility of code / data leaks by throwing a compiler exception if
  106259
July 23, 2019 20:24 claude.pache@gmail.com (Claude Pache)
> Le 23 juil. 2019 à 19:54, G. P. B. banyard@gmail.com> a écrit : > > The only point of contention of this RFC that I potentially see is the > removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 > instead of it being removed in PHP 9 after it having had a whole major > version release cycle.
Realistically, a non-negligible proportion of users will jump from PHP 7.x to 8.1 or 8.2; so that having the parse error behaviour in 8.0 only is in no way safer for them. It is more reasonable to keep the parse error behaviour for all 8.x versions. —Claude
  106260
July 23, 2019 20:40 r@roze.lv ("Reinis Rozitis")
> First, short_open_tag is an ini setting that control core language syntax. This means that their use is not possible in portable code, because the code author does not necessarily have the necessary control over the configuration of the deployment environment.
While this RFC is a much better way of deprecating the feature (looking at the previous votes it most likely will happen), the reasoning/text (main point) is still odd: - if the code author wants a portable code he HAS the necessary control over it and can always follow the coding guidelines and write it using '
  106272
July 24, 2019 00:28 markyr@gmail.com (Mark Randall)
I continue to find motivations #1 and #3 utterly bizarre, especially 
that "open tags not being compatible with XML" is still being used as a 
justification.

That said, the depreciation and removal process looks solid, with the 
exception of complete removal in PHP 8.1.

I must question if people are really so desperate to use > Hello internals,
> https://wiki.php.net/rfc/deprecate_php_short_tags_v2
  106277
July 24, 2019 03:51 vsuraski@gmail.com
> -----Original Message----- > From: G. P. B. banyard@gmail.com> > Sent: Tuesday, July 23, 2019 8:55 PM > To: PHP internals <internals@lists.php.net>; Derick Rethans <derick@php.net>; > Peter Kokot <petk@php.net> > Subject: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2 > > Hello internals, > > Due to the controversy after the initial vote on the Deprecate PHP's Short Open > Tag RFC [1] here is a new RFC to deprecate them written with the help of Nikita > Popov <nikic@php.net>. >
George, Thanks for creating a new RFC instead of going into a bit of a procedural limbo. I appreciate that. Everyone, Much of the feedback for v2 was around the problematic idea of changing behavior between 8.0 and 8.1, but little was said on the premise of the proposal itself. Much like the original RFC, the rationale for this deprecation remains quite weak. The differences are that it's clearer now (3 separate motivations were rightfully condensed into just 1), and the bogus motivation that this would somehow simplify the parser was removed. But same as with the original RFC - this RFC creates the impression of a problem that doesn't really exist, and then provides a way of fixing it - while the 'do nothing' option remains a vastly superior outcome in terms of gain vs. harm. The simple reality is this: - Absolutely nothing changed about internals@. I'll be happy to add them (of course, in a condensed summarized fashion). Thanks, Zeev
  106280
July 24, 2019 08:32 phpmailinglists@gmail.com (Peter Bowyer)
On Tue, 23 Jul 2019 at 21:56, Nikita Popov ppv@gmail.com> wrote:

> I did not want to just merge the original (accepted!) implementation after > the controversial discussion it triggered, but after reading this, I > realize that I just wasted my time here. So much for being nice and giving > people a fair change to reevaluate the proposal in light of the new > arguments that have been brought forward. I guess that next time I'll just > go ahead and merge things.
On Wed, 24 Jul 2019 at 04:51, <vsuraski@gmail.com> wrote:
> - The motivation for removing short tags today is a lot weaker than the > motivation was not to add it in the first place back in 1998 (XML being a > lot less important). This makes for an unreasonable basis for deprecation. >
I think it fair to say: 1. The RFC to remove short open tags passed 2. The backwards-compatibility break is contentious I move an alternative motion: that short open tags do not change in PHP 7.4, throw a deprecation warning in PHP 8.X, and what happens next (e.g. removal) is left for a future, PHP 9 RFC. The manual is updated to say they are deprecated and will be removed in future, to dissuade new usage. Sure, this is "kicking the can" down the road. It's also a proposal I hope both sides can support. Peter
  106301
July 25, 2019 22:40 terry@terah.com.au (Terry Cullen)
________________________________
From: vsuraski@gmail.com <vsuraski@gmail.com>
Sent: Wednesday, 24 July 2019 1:51 PM
To: 'G. P. B.' banyard@gmail.com>; 'PHP internals' <internals@lists..php.net>
Subject: RE: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2



> -----Original Message----- > From: G. P. B. banyard@gmail.com> > Sent: Tuesday, July 23, 2019 8:55 PM > To: PHP internals <internals@lists.php.net>; Derick Rethans <derick@php.net>; > Peter Kokot <petk@php.net> > Subject: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2 > > Hello internals, > > Due to the controversy after the initial vote on the Deprecate PHP's Short Open > Tag RFC [1] here is a new RFC to deprecate them written with the help of Nikita > Popov <nikic@php.net>. >
George, Thanks for creating a new RFC instead of going into a bit of a procedural limbo. I appreciate that. Everyone, Much of the feedback for v2 was around the problematic idea of changing behavior between 8.0 and 8.1, but little was said on the premise of the proposal itself. Much like the original RFC, the rationale for this deprecation remains quite weak. The differences are that it's clearer now (3 separate motivations were rightfully condensed into just 1), and the bogus motivation that this would somehow simplify the parser was removed. But same as with the original RFC - this RFC creates the impression of a problem that doesn't really exist, and then provides a way of fixing it - while the 'do nothing' option remains a vastly superior outcome in terms of gain vs. harm. The simple reality is this: - Absolutely nothing changed about internals@. I'll be happy to add them (of course, in a condensed summarized fashion). Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi Internals, I completely agree with Zeev here. When I first saw this RFC get proposed I though to myself that there's no chance this will get accepted as the epic amount of legacy code using this feature would need to be changed and the justification was too weak. Wow... how wrong I was. Personally, I've written many of medium/large PHP apps for businesses over the last 16 years all of which use short tags. Many of which are still running but the owners of these projects are not interested in spending any money on pointless updates and will simply stop upgrading PHP. I'm a big supporter the direction PHP is going in with types and alike but this one has jumped the shark. Terry Cullen
  106278
July 24, 2019 03:54 zeev@php.net (Zeev Suraski)
[Had an issue with my email client, apologies if it ends up being sent
twice]

On Tue, Jul 23, 2019 at 8:55 PM G. P. B. banyard@gmail.com> wrote:

> Hello internals, > > Due to the controversy after the initial vote on the Deprecate PHP's Short > Open Tag RFC [1] here is a new RFC to deprecate them written with the help > of Nikita Popov <nikic@php.net>. >
George, Thanks for creating a new RFC instead of going into a bit of a procedural limbo. I appreciate that. Everyone, Much of the feedback for v2 was around the problematic idea of changing behavior between 8.0 and 8.1, but little was said on the premise of the proposal itself. Much like the original RFC, the rationale for this deprecation remains quite weak. The differences are that it's clearer now (3 separate motivations were rightfully condensed into just 1), and the bogus motivation that this would somehow simplify the parser was removed. But same as with the original RFC - this RFC creates the impression of a problem that doesn't really exist, and then provides a way of fixing it - while the 'do nothing' option remains a vastly superior outcome in terms of gain vs. harm. The simple reality is this: - Absolutely nothing changed about internals@. I'll be happy to add them (of course, in a condensed summarized fashion). Thanks, Zeev
  106379
August 5, 2019 18:46 zeev@php.net (Zeev Suraski)
As we head closer to the vote - and in light of what I said towards the end
of my message in https://externals.io/message/106256#106278, as well as the
points Dan articulated regarding the current issue of negative feedback not
getting the same level of visibility as the RFC itself - I'd like to figure
out a temp solution until we amend our rules.

George - are you OK with having a section that illustrates the issues that
me and some others have brought up with this deprecation in the RFC
itself?  Or add a link to a separate page, along the lines of what Dan
proposed?

Thanks,

Zeev

On Tue, Jul 23, 2019 at 8:55 PM G. P. B. banyard@gmail.com> wrote:

> Hello internals, > > Due to the controversy after the initial vote on the Deprecate PHP's Short > Open Tag RFC [1] here is a new RFC to deprecate them written with the help > of Nikita Popov <nikic@php.net>. > > This RFC is targeting PHP 7.4 and has an exemption to land after the > feature freeze granted by the Release Managers of PHP 7.4 Derick Rethans < > derick@php.net> and Peter Kokot <petk@php.net>, CCed to this email. > > https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > > Discussion is expected to last 2 weeks followed by a 2 week vote such that > this RFC may land in PHP7.4Beta3 as per the timeline. [2] > > The only point of contention of this RFC that I potentially see is the > removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 > instead of it being removed in PHP 9 after it having had a whole major > version release cycle. > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags > [2] https://wiki.php.net/todo/php74 >
  106380
August 5, 2019 19:05 george.banyard@gmail.com ("G. P. B.")
On Mon, 5 Aug 2019, 20:47 Zeev Suraski, <zeev@php.net> wrote:

> As we head closer to the vote - and in light of what I said towards the end > of my message in https://externals.io/message/106256#106278, as well as > the > points Dan articulated regarding the current issue of negative feedback not > getting the same level of visibility as the RFC itself - I'd like to figure > out a temp solution until we amend our rules. > > George - are you OK with having a section that illustrates the issues that > me and some others have brought up with this deprecation in the RFC > itself? Or add a link to a separate page, along the lines of what Dan > proposed? > > Thanks, > > Zeev >
I'd prefer Dan's approach and having a seperate page linked at the top of the RFC. I'll start voting tomorrow and will link to your page in the same message as the voting announcement. Best regards George P. Banyard
>
  106381
August 5, 2019 22:50 zeev@php.net (Zeev Suraski)
On Mon, Aug 5, 2019 at 10:05 PM G. P. B. banyard@gmail.com> wrote:

> > I'd prefer Dan's approach and having a seperate page linked at the top of > the RFC. > > I'll start voting tomorrow and will link to your page in the same message > as the voting announcement. >
Thanks George. I created a page with a counterargument to the deprecation proposal here: https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags and linked it from the RFC. If others have additional input to add there, please let me know. Zeev
  106382
August 5, 2019 22:54 george.banyard@gmail.com ("G. P. B.")
On Tue, 6 Aug 2019 at 00:50, Zeev Suraski <zeev@php.net> wrote:

> > > On Mon, Aug 5, 2019 at 10:05 PM G. P. B. banyard@gmail.com> wrote: > >> >> I'd prefer Dan's approach and having a seperate page linked at the top of >> the RFC. >> >> I'll start voting tomorrow and will link to your page in the same message >> as the voting announcement. >> > > Thanks George. I created a page with a counterargument to the deprecation > proposal here: > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags and > linked it from the RFC. > > If others have additional input to add there, please let me know. > > Zeev >
Thanks for taking care of this and adding a link in the header of the RFC. George P. Banyard
  106383
August 6, 2019 10:26 petercowburn@gmail.com (Peter Cowburn)
On Mon, 5 Aug 2019 at 23:51, Zeev Suraski <zeev@php.net> wrote:

> On Mon, Aug 5, 2019 at 10:05 PM G. P. B. banyard@gmail.com> wrote: > > > > > I'd prefer Dan's approach and having a seperate page linked at the top of > > the RFC. > > > > I'll start voting tomorrow and will link to your page in the same message > > as the voting announcement. > > > > Thanks George. I created a page with a counterargument to the deprecation > proposal here: > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags and > linked it from the RFC. > > If others have additional input to add there, please let me know. >
Please keep this sort of content inside the relevant mailing list thread, we don't need yet more places to go hunting for comments on RFCs. I'm not sure what the value is of a dedicated wiki page is (for context, I have read Dan's thread suggesting the idea), other than to have a new soap box to shout from for the most loud voices. Key feedback to RFCs should at minimum appear in the respective discussion thread on the list. If it does, then this page is redundant. If it doesn't, then it should.
> > Zeev >