Re: Re: com php-src: Bug 49898 __getCookies() method implementation: ext/soap/soap.c ext/soap/tests/bug49898.phpt

From: 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

« previous php.internals (#75000) next »