Re: Re: com php-src: Bug 49898 __getCookies() method implementation: ext/soap/soap.c ext/soap/tests/bug49898.phpt
| From: | Stas Malyshev | Date: | Thu, 19 Jun 2014 19:59:28 +0000 |
| Subject: | Re: Re: com php-src: Bug 49898 __getCookies() method implementation: ext/soap/soap.c ext/soap/tests/bug49898.phpt | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75000@lists.php.net to get a copy of this message | ||
Hi!
> Reading this post tells me exactlt why new features should go in x.y+1. It
> is a pain to figure which point versions introduced which features. Always
> was.
You seem to be ignoring the fact that 5.5 is adopted by less than 10% of
the market. This means if we say new features go only into 5.6, even
minor ones like adding an obvious function, that is essentially saying
to the vast majority of users "if you submit a pull now, you's probably
get to use it about 2-3 years from now". It's not what people expect
from an actively used open-source project, I think.
I understand that maintaining version requirements with essentially 4
active versions on the market may be a pain, and if you have any ideas
of how to improve it, you're most welcome. We used to have a DB that
listed all functions by the version they appeared in, sadly now it seems
to be unmaintanied for years, and we could revive it and make it into an
API and a fully automatic tool generating the requirements for
practically any sane code (composer integration anyone?). There might be
other solutions for that.
But I do not think saying "we'll stop adding anything at all and if you
want a minor addition you need to wait for version x.y+1, probably a
year or so till the release and then another couple of years until your
ops org is ready to adopt it" - is a solution. I think this will have
very negative effect on people's willingness to contribute and on
improvement of PHP.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227