Hello,
I was wondering if it would be useful to add GitHub milestones for the
PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
https://github.com/php/php-src/milestones
Because some pull requests might target versions after the PHP-8.4 and it
might be useful to have them additionally
On Tue, 26 Mar 2024 at 06:41, youkidearitai wrote:
>
> Hi, Internals
>
> Sorry I mistake.
> Send again.
>
> grapheme_str_split going to "Voting" phase.
> Vote end is 10th April 00:00 GMT
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> -
On Tue, 5 Mar 2024 at 01:27, wrote:
>
> > The VSC part from github (hosting our code), can very easily be ported.
> > Issues, discussions etc can not.
> >
> > With the ongoing enshittification of most of the Internet due to
> > advertising and tracking, we'd be negligent not hosting and owning
On Mon, 12 Feb 2024 at 12:13, Ilija Tovilo wrote:
>
> Hi Yuya
>
> It seems you accidentally sent your response to me instead of the list.
>
> On Sun, Feb 11, 2024 at 5:10 PM youkidearitai wrote:
> >
> > 2024年2月11日(日) 21:18 Ilija Tovilo :
> > >
> > > Hi everyone.
> > >
> > > I would like to start
On Thu, 2 Nov 2023 at 05:02, Christopher Jones
wrote:
>
> On 2/11/2023 2:46 am, Derick Rethans wrote:
> > Hi,
> >
> > I have just opened voting on the RFC to unbundle imap, pspell, and
> > oracle integrations.
>
> :)
>
> --
> https://twitter.com/ghrd
>
> --
> PHP Internals - PHP Runtime
On Tue, 5 Sept 2023 at 11:40, Hanz wrote:
> Hello,
>
> Ran into a couple of issues with RC1 that I haven't seen online.
>
> With --with-pear: The --with-pear option is deprecated
>
> With --enable-pear: configure: WARNING: unrecognized options: --enable-pear
>
> I'm using --disable-all as the
On Mon, 14 Aug 2023 at 16:18, G. P. B. wrote:
> Hello internals,
>
> While working on some DNF type bugs, I discovered some major issues around
> the disable_classes INI setting implementation. Such as:
>
> - A double-free of the type of a typed property
> - A use after free (which segfaults)
On Tue, 11 Jul 2023 at 13:37, Levi Morrison wrote:
>
> On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote:
> >
> > Chatter on the [Interface Default Methods RFC][1] has been quiet for
> > the past 6 days, and the feature freeze deadline is fast approaching
> > for PHP 8.3, so I'm moving this to
On Fri, 28 Apr 2023 at 12:01, Jakub Zelenka wrote:
>
> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub
It would be also good to know why people vote no.
--
PHP Internals -
On Wed, 12 Apr 2023 at 15:53, Alex Wells wrote:
>
> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely
On Wed, 22 Feb 2023 at 14:14, Max Kellermann wrote:
>
> On 2023/02/22 13:45, Max Kellermann wrote:
> > 13 years ago, there was commit
> > https://github.com/php/php-src/commit/477649cd3f09 which attempted to
> > fix this, but was reverted on the same day by commit
> >
On Sun, 12 Feb 2023 at 09:31, Max Kellermann wrote:
>
> On 2023/02/11 17:14, Peter Kokot wrote:
> > I've voted in favor of the RFC because of the code-cleaning,
> > tech-debt-reducing improvements to code readability.
>
> Exactly my point, and I'm surprised by the
On Wed, 1 Feb 2023 at 13:14, Max Kellermann wrote:
>
> On 2023/01/30 11:26, Max Kellermann wrote:
> > If nobody objects, I'll announce the start of voting on February 1st.
>
> That's today.
>
> Voting starts now, please vote on my RFC:
> https://wiki.php.net/rfc/include_cleanup
>
> Original
On Sat, 10 Sept 2022 at 11:32, Yasuo Ohgaki wrote:
>
> 2022年9月7日(水) 22:58 Misha :
>
> > Hello everyone,
> >
> > We spend a lot of time to increase limits for uploads file in PHP. Can we
> > increase it in php.ini?
> >
> > Current value is 2Mb. Its so small value, when photo image can take 8Mb on
On Wed, 8 Jun 2022 at 20:16, shinji igarashi wrote:
> > declare(ignore_newline_after_close_tag=false);
>
> Thanks for coming up with another idea!
>
> As others have already pointed out, disabling the closing tag from
> eating trailing newline throughout the file would be inconvenient if
> we
On Mon, 22 Mar 2021 at 18:23, Guilliam Xavier wrote:
>
> On Mon, Mar 22, 2021 at 5:23 PM G. P. B. wrote:
>
> >
> > The thing is that by my recollections votes have already been extended.
> > Mostly when there has been issues with the mailing list, or some outside
> > event.
> >
> > Moreso, I
Hello everyone,
I'm just adding a few cents into this discussion.
I've voted "yes" because we don't have any other async stuff RFCs available
nor in the preparation. PHP needs such functionalities very badly and very
quickly to sort of speak. Adding a brand new extension in the core is maybe
a
But hopefully the relevant
emails could be approved on time anyhow.
Cheers.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
at have been showing that this is actually
possible. How smart this is for the PHP progress is another story, but
for the business it might be good to think about this also I guess:
https://github.com/microsoft/php-src/releases
So, to make some sort of a milestone with some of the versions -
either 8 or 9 or something.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 6 Sep 2019 at 11:11, Rowan Tommins wrote:
>
> On Thu, 5 Sep 2019 at 22:45, Peter Kokot wrote:
>
> > GitHub usage is inevitable.
>
>
>
> Did you use the wrong word here, or are you saying that, of all the
> hundreds of different platforms we could investigate
(several 10 years) discussion comments. This is not a problem
because even with having an email archive online very rarely someone
will return to such discussion. RFC content is there and will be there
for PHP to move "elsewhere" though if such hypothetical case comes.
Tank you.
--
ith the
> defaults would be a good idea but then I'm not totally sure what it's point
> *would* be.
>
> Best regards
>
> George P. Banyard
About the error_reporting, I always set this to E_ALL for all
environments also, yes.
Syncing with the php.ini-production would probably make more sens
On Tue, 20 Aug 2019 at 23:37, Rowan Tommins wrote:
>
> On 20/08/2019 22:18, Peter Kokot wrote:
> >> The approach was: add the deprecation notice in PHP 8, and remove short
> >> open tags in PHP 9 or PHP 10 (purposely left vague to get more support for
> >> the
On Tue, 20 Aug 2019 at 19:47, Peter Bowyer wrote:
>
> On Tue, 20 Aug 2019 at 17:18, Peter Kokot wrote:
>>
>> Let's simplify this a bit because I'm not sure I have seen anyone
>> mentioning something like a PHP 10 milestone in all these discussions.
>> If we want t
On Tue, 20 Aug 2019 at 18:39, Rowan Tommins wrote:
>
> On 20/08/2019 17:18, Peter Kokot wrote:
> > About the docs - there are
> > very minor changes needed where "backwards compatibility" is mentioned
> > maybe. Because they are not in PHP for keeping BC anymore
On Tue, 20 Aug 2019 at 18:02, Chase Peeler wrote:
>
> On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot wrote:
>
> > On Tue, 20 Aug 2019 at 14:51, G. P. B. wrote:
> > >
> > > Hello internals,
> > >
> > > This RFC has been declined with
tions out there. short
tags will stay in PHP for at least another 10+ years, so maybe we
should simply consider them not a part of legacy but a special kind of
a feature. There are some parts in PHP comments and docs that needs
this fixed and sorted out better a bit (probably - specially in the
i
anization. Even with a list of branches that someone with
access might even mistakenly pushed to origin decades ago.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
can see the results before the voting
phase and if the time investment is worth the trouble of adding a
feature or not.
Thank you.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
P will now never be a consistent language
and short tags will be forever in so we will all be able to support
Chase's gigantic legacy project forever?
Solution would be if we can make this issue that was mentioned:
- elephpant vs elep++ant
into a similar issue as is now:
- elephpant vs elephpan
On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, wrote:
> > It is surprising how thing that is considered by one to be a security
> risk, is treated
> > as nothing relevant by others. This dichotomy is quite disturbing - in
> what case
> > removing security risk is "no real gain"?
>
> It's
On Wed, 14 Aug 2019 at 11:09, Christian Schneider wrote:
>
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
> >> The best counterargument I can give against "cleaning up" is that it takes
> >> energy away from actual new features, even if it's just the
l energy of
> monitoring and responding to long threads like this one.
>
> Regards,
Code is like a garden. If there are unwanted weeds and nobody cleans
them up, the flowers don't shine and grow as they should. Cleaning of
the weeds is just as important as new features. A bit less but
important.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
something like that.
Where developer would have option to enable it and use "traditional"
or whatever named PHP functionalities such as short tags and things
that cause so many issues and being sidelines. Without enabling (or
importing that), PHP would behave more futuristic oriented.
There
run
(PHP 9 etc)... With more and more ambiguities, inconsistencies,
lockups, and dead ends behind the language there is probably also a
bit of a factor to consider that it lowers this attractiveness.
Meaning less people will think of adopting it (with all the things
combined - short tags, that and that inconsistency not being removed
from PHP due to major disastrous BC break there and there). So, the
damage is also on the long run with more and more locks and dead ends
not being able to be fixed and cleaned.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 8 Aug 2019 at 00:38, Zeev Suraski wrote:
>
>
>
> On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot wrote:
>>
>> Thank you for such a detailed response. Ok, I understand then. Then
>> next logical step here is - I would maybe want to use th
On Wed, 7 Aug 2019 at 21:25, Zeev Suraski wrote:
>
>
>
> On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot wrote:
>>
>> Considering that you're in favor of keeping the short opening tag in
>>
>> PHP "forever" because you haven't added any kind of other solu
Hello,
On Wed, 7 Aug 2019 at 19:03, Chase Peeler wrote:
>
>
>
> On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot wrote:
>>
>> Hello.
>>
>> On Wed, 7 Aug 2019 at 18:56, Chase Peeler wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019
Hello.
On Wed, 7 Aug 2019 at 18:56, Chase Peeler wrote:
>
>
>
> On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot wrote:
>>
>> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd
On Wed, 7 Aug 2019 at 16:14, Zeev Suraski wrote:
>
>
>
> On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd wrote:
>>
>> On Wed, 7 Aug 2019 at 09:45, Peter Kokot wrote:
>> >
>> > Yes, last time I was asking this, there was a clarification that
>> &g
, visit: http://www.php.net/unsub.php
>
Yes, last time I was asking this, there was a clarification that
certain people from the group internals can veto particular RFC. So, I
think that this is the case here.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
been reached on
the original RFC. Since the original RFC has been vetoed and so much
energy was invested from Zeev and some others commentators then I
guess the RFCs fail and we will have two types of opening tags in PHP
for ever. Otherwise, as described, yes.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 28 Jun 2019 at 17:57, Christoph M. Becker wrote:
>
> On 28.06.2019 at 17:49, Peter Kokot wrote:
>
> > On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev
> > wrote:
> >>
> >>> ext/imap should follow the same road.
> >>>
> >&g
up, we can always
> move it back.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Hello, sorry for bumping this one. Is the ext/xmlrpc extension also
On Wed, 12 Jun 2019 at 14:29, Sascha Schumann
wrote:
>
> Please try again.
>
> Sascha
Great. Now it works. Thank you so much, Sascha...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
icate'.
For the www.php.net page this works ok:
wget https://www.php.net/distributions/php-7.3.6.tar.xz
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On Sat, 11 May 2019 at 20:56, Peter Kokot wrote:
>
> Not trying to rush anyone to something they have no energy working on
> anymore here but what's the plan here then? And what plan is there
> with these short tags on the long run?
I'm just checking then why is this RFC in
Hello,
On Sat, 18 May 2019 at 22:02, Peter Kokot wrote:
>
> Hello,
>
> On Sat, 18 May 2019 at 12:06, Joe Watkins wrote:
> >
> > Hi all,
> >
> > Does anyone know what is the cause of all the spam from the announce
> > mailing list? I'm not sure who i
an someone do some magic, and make it go away please ?
>
> Cheers
> Joe
100+ daily spam emails here also. Considering that these don't get to
other mailing lists, they can get regulated probably...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 11 May 2019 at 06:12, Pierre Joye wrote:
>
> On Fri, May 10, 2019, 2:06 PM Peter Kokot wrote:
>
> >
> > The images for such C software are one of the more useless ones. Snaps
> > or custom Linux repositories are the way to go here. Because of the
> > in
et worse actually from release to
release each year if we don't start refactoring some things. And the
manual for the installation of PHP that doesn't mention such options
(but on the other hand mentions installing PHP on servers that are
dead for decade) is also another story that plays a rol
coming
enough) to send your pull request there. If not ping me up to check
your pull requests per manual basis.
A friendly nudge to the organizers... Next time, don't be shy and
please please avoid doing forks of this repo and let's do the noise
directly on the php-src repo. As we see, it is almost nea
deprecation warning is self-evident and
therefore I'm not sure why the additional vote here. Because again, an
edge case scenario we could get a changed functionality in PHP 8 and
no warning in PHP 7.4.
Just as an example and a bit of an additional info how the upgrades
from minor to major releases ca
blem on a scale of an elephant, that I don't
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used anymore in any case. :) Because obviously a very
large number of people would like to have more clear def
ything
in between is a more or less a revert of the original RFC which would
then come to a question of why making these RFCs at all and why voting
even matters.
Without these kind of "hacks" PHP wouldn't even move forward anymore.
Contributing to it would be in most cases only maintenance, fixing
bugs and compatibility with platforms out there. So nothing exciting
anymore like making it more syntactically correct, more logical etc.
(these are very important changes also beside new functionality and
extensions).
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
pps will work ok on PHP 8.0 also met)
- Actual removal in PHP 9 (because this is then the logical next
step). Removing something like this in PHP 8.1 is not following
semantic versioning at all. Either removal in 8.0 or 9.0.
Cheers and thanks.
--
Peter Kokot
--
PHP Internals - PHP Runtime Developmen
w.
Worth noting that now both domains result in 200 OK (previously there
was a redirection done from php.net to www.php.net):
curl -IL https://www.php.net
curl -IL https://php.net
Thank you...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
one as a separate
project out of php for starters if anyone might be interested in doing
that.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On Thu, 25 Apr 2019 at 09:15, Nikita Popov wrote:
>
> Hi internals,
>
> As already discussed in the corresponding voting thread, the deprecation of
> short tags as proposed has a high risk of causing inadvertent source code
> leakage. The RFC proposes to change the default of
in PHP are using these anymore for a
very long time. If they postpone upgrades and neglect good coding
practices, nothing can help them improve or fix their apps.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
; On Wed, 24 Apr 2019, 19:10 Christian Schneider, > >
> > > wrote:
> > > > Am 24.04.2019 um 19:01 schrieb Peter Kokot :
> > > > > just a friendly reminder that by the time one writes an email here
> > > > > these tags can be already replaced
/to/php/files/with/short/tags
And then actually replacing them (without dry run):
php-cs-fixer fix --rules=full_opening_tag --diff
/path/to/php/files/with/short/tags
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On Wed, 24 Apr 2019 at 13:29, G. P. B. wrote:
>
> Hello Internal,
>
> The two weeks of voting have now ended.
> The results are 38 for and 18 against (total 56) for the primary vote to
> deprecate PHP's short open tag in PHP 7.4.
> This passes in favor with 68%.
>
> The results are 42 for
nally proposed.
>
> Regards,
> Nikita
Thanks for the RFC. The status of the document should be probably
updated from "Status: Under Discussion" to "Status: Voting"
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
...
Thank you.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
es.
Also, practice shows that the dev branch in state before the few
months prior to the releases contains really a lot of bugs and also
build system bugs that normal users will have serious issues setting
this up. If Linux packagers and 3rd party repository maintainers can
help here, that would be also one way to go since PHP seems to be very
far away from doing such steps on the php.net side...
But to have PHP 8.0.0alpha1 version available at this and this date
before the PHP 7.4 release is quite challenging for all, I think.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
integration of JIT with VM.
>
>
> Thanks. Dmitry.
Great. No rush, we now have more than a year until Jit will be happening then :)
Otherwise, I'm really looking forward seeing this in action. Thank you
for the splendid work.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mail
. There are only two
tags really needed in PHP templating engines https://fb.com/groups/2204685680/permalink/10157687999015681/
Best regards.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ated usage from their code and move to
something else. Not that they will have an option to install it over
PECL in PHP 8.0... Is this ok approach for this case? Because with
this approach PHP is also saying quietly that PECL is a museum for
extensions and not a place for developing them further. I mig
also about removing deprecated functionality. This
approach is actually following semver https://semver.org, so that's
all good I think.
In any case if we will need to wait more than another year or not,
thank you for your great work. Thumbs up. :)
--
Peter Kokot
--
PHP Internals - PHP Runtime Develo
hout
opening tag might go through also. After all, text files are simple.
Something on this was already being done and probably also discussed:
https://wiki.php.net/rfc/nophptags
On the other hand, shebangs will still be present in CLI scripts. For example:
#!/usr/bin/env php
--
Peter Kokot
--
b.php
>
In reality if developer wants to write "portable" and proper PHP code,
no one actually should use these short tags anymore. If they are still
used somewhere as part of some legacy code, they won't work on
majority of PHP installations anymore because the mostly have these
turned off
On Tue, 12 Mar 2019 at 12:15, Alexandru Pătrănescu wrote:
>
> Hi,
>
> I guess that `short_open_tag` ini settings can be deprecated/removed.
> But that would mean that short open tags will be always available, not that
> it will be removed.
>
> Regards,
> Alex
Oh, the main idea is to remove the
Hello,
On Tue, 12 Mar 2019 at 10:51, Rowan Collins wrote:
>
> On Mon, 11 Mar 2019 at 20:06, G. P. B. wrote:
>
> > From my understanding, the ` > so maybe we should deprecate PHP's short tag altogether?
> >
>
>
> I think when that's been proposed in the past, people have said they like
> it for
gt; Joe
>
> On Wed, 6 Mar 2019 at 10:39, Kalle Sommer Nielsen wrote:
>
> > Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov :
> > >
> > > On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann
> > wrote:
> > >
> > > > Am 06.03.201
ging left-hand traffic countries to use right-hand
traffic. A new function name would be needed for that. You can start
with creating an extension for this... But with this level of
communication? Hm...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 18 Feb 2019, 23:39 Legale.legale I have made super simple OS independent phpenmod.
>
> Https://github.com/legale/phpenmod
> On Feb 18, 2019 23:31, Gabriel Ostrolucky wrote:
> >
> > I'm fan of this idea. I miss this in any other non-debian distro.
> > What nobody mentioned yet, similar
no commit.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
+1 Yes, please...
For a better overview of these:
https://github.com/php/php-src/branches/stale?page=12
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 7 Feb 2019 at 18:01, Peter Kokot wrote:
>
> Hello,
>
> On Thu, 7 Feb 2019, 16:52 Christoph M. Becker >
>> On 07.02.2019 at 16:14, Sjon Hortensius wrote:
>>
>> > On Wed, Feb 6, 2019 at 4:14 PM Ben Ramsey wrote:
>> >
>> >>> On
Hello,
On Thu, 7 Feb 2019, 16:52 Christoph M. Becker On 07.02.2019 at 16:14, Sjon Hortensius wrote:
>
> > On Wed, Feb 6, 2019 at 4:14 PM Ben Ramsey wrote:
> >
> >>> On Feb 6, 2019, at 01:22, Peter Kokot wrote:
> >>> I can help sort this mess.
n the commit
log properly and credits section is added as a recognition for the
volunteers (as noted in the php test fest instructions and all).
Let me know when we start adding those. Have a nice day.
[1] https://github.com/phpcommunity/phptestfest-php-src/pulls
--
Peter Kokot
--
PHP Internals -
hub.com/php/php-src/blob/master/README.MAILINGLIST_RULES
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 4 Feb 2019, 02:32 Peter Kokot On Wed, 30 Jan 2019 at 13:57, Derick Rethans wrote:
> >
> > On Mon, 28 Jan 2019, Zeev Suraski wrote:
> >
> > >
> > > > I would like to make two changes to this header:
> > > >
> > > > 1. Ch
sign/infrastructure/app
changes and then opening a discussion on the webmaster mailing list to
even start considering it. We need to start giving hints and make
decisions before that step if this can be done on time.
- *.php.net sites under one roof maybe sound useful but separate
"services" (as
llo,
I've prepared quick pull request [1] that fixes the missed headers in
source code files and additionally bumps or changes the year range on
other places.
Questions:
1.) What should "php -v" output regarding copyrights and year ranges?
2.) What should "man php" include under the COPYRIGHT section
regarding the year ranges?
3.) Similarly, should there be a common pattern for places like
phpinfo() output?
Thanks.
[1] https://github.com/php/php-src/pull/3791
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, PECL admins can simply set the package as "superseded by"
another package. For example:
https://pecl.php.net/package/date_time
If another "weakref" PHP extension will be developed elsewhere,
different naming can be picked for PECL or if that extension will
return to development, diffe
a better start with this.
Except that here we need to understand that PHP packages on Linux
distributions are already compiled and prepared for faster
installation, so installing extensions with PECL is a way different
approach compared to a more comfortable ways using
apt/yum/dnf/pacman/brew...
-
that lack handling extensions
(we were just discussing PECL for example in some other thread)...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
timeline simulation where BC breaks are allowed:
PHP 10.0.0 2031
PHP 9.0.0 2026
PHP 8.0.0 2020-2021
PHP 7.0.0 2015-12-03
PHP 5.0.0 2004-07-13
PHP 4.0.0 2000-05-22
[2] https://github.com/php/php-src/blob/master/makedist#L118
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
ut a patch. I mean if there are maintainers, and people who want
to keep this PEAR in the php-src repository, fine I guess. But then
I'm not sure what can be done here anyway...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ll Linux
distributions. I don't like the sound of that.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
replacement for current pecl script?
With only disabling installation option, nothing major is done
actually, I think but if there is some other plan here that +1 I
guess.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 30 Jan 2019 at 20:51, Rowan Collins wrote:
>
> On 30/01/2019 17:28, Peter Kokot wrote:
> > This now also means that PHP is making its inconsistency a fact
>
>
> The inconsistency IS a fact, and has been for more than 20 years. This
> isn't some new policy, ban
t who am I to judge this state now. It would be good to avoid having
FAQs and appendixes in coding standards for those
function_name_ext_SomethingElseOutofblue() cases so that it might be
still achieved one day.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, which we do not collect.
>
> We could also just drop the header entirely, I'm just proposing these two
> changes as the path of least resistance towards getting the "annoying"
> parts removed.
>
> Regards,
> Nikita
And maybe also additional change from:
http://www.p
Hello,
On Tue, 22 Jan 2019 at 16:49, Levi Morrison wrote:
>
> On Wed, Nov 29, 2017 at 2:54 PM Peter Kokot wrote:
> >
> > Hello,
> >
> > I'm not sure if this has been discussed before, but I find these local
> > variables in C, H and other files a bit strange
On Wed, 29 Nov 2017 at 22:53, Peter Kokot wrote:
>
> Hello,
>
> I'm not sure if this has been discussed before, but I find these local
> variables in C, H and other files a bit strange and bloated:
>
> /*
> * Local variables:
> * tab-width: 4
> * c-basic-offset:
does) or something else
such as CMake.
If there are any objections in this regard, let me know please so we
don't remove maybe something important from the contextual
understanding of the PHP build system itself.
Thank you.
[1] https://github.com/php/php-src/pull/3694
--
Peter Kokot
--
PHP
4LEr13OaAlvs53niFo7r4sYzayKZdM
> NuNEQaXP7r5kS40Aqn/gjofIDg6j+4ni9atAwcbVY328iA4J5W5OWfS+XI5tSrs=
> =3ABE
> -END PGP SIGNATURE-
>
> Cheers
> Joe
Hello, thank you for the release, there is also a PHP-7.21 tag which
might be an issue when the final is released:
https://g
1 - 100 of 109 matches
Mail list logo
