Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 3 April 2015 05:55:27 GMT+01:00, Stanislav Malyshev wrote: >Hi! > >> +1 This is exactly it. The longer older versions are "supported" the >> longer they remain in the wild. > >5.3 is unsupported and still has over 40%. 5.2 is dead for 4 years by >now and still beats 5.5 by factor of more than 2. So I don't think just >unsupporting something will make a big difference there. The problem is that all the stats we have cover versions that predate the current release process. We've actually only had two "minor releases" under the new definition, 5.5 and 5.6; and the next release is a major, so will be different again. If we have a smooth series of 7.x releases, we may see a very different pattern of adoption in, say, 5 years time. Unfortunately, we can't wait until then to decide on change policy, because the policy is required to get that adoption. So ultimately, we have to make some informed guesses based on feedback, logic, and experience outside the project, about the impact of different kinds of process. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Apr 3, 2015 11:55 AM, "Stanislav Malyshev" wrote: > > Hi! > > > +1 This is exactly it. The longer older versions are "supported" the > > longer they remain in the wild. > > 5.3 is unsupported and still has over 40%. 5.2 is dead for 4 years by > now and still beats 5.5 by factor of more than 2. So I don't think just > unsupporting something will make a big difference there. We see progresses with linux distributions, thanks our release process RFC. Yes significant changes have to be seen once users migrate to these versions. Ignoring this fact is dangerous, especially if it used to take decisions about adding features to patch releases (arguments why already mentioned). > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > +1 This is exactly it. The longer older versions are "supported" the > longer they remain in the wild. 5.3 is unsupported and still has over 40%. 5.2 is dead for 4 years by now and still beats 5.5 by factor of more than 2. So I don't think just unsupporting something will make a big difference there. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > It seems to me we are mixing two questions : can 'small > self-contained' changes be introduced in a patch release, and how > 'small' and 'self-contained' a change must be not to require an RFC ? > It seems implicit that, once an RFC is written, it is not a 'small > self-contained' change anymore. Having RFC is not related to change being self-contained, but rather with if the change is obvious or needs more thorough discussion. *Usually* the latter would also not be small, but not in every case. On the other hand, the change may be needing thorough discussion, but when the discussion has been done, the code change itself may be tiny and self-contained. So it's not the same. > One example : https://wiki.php.net/rfc/cyclic-replace can probably be > considered as a 'small self-contained' addition. Should I continue > with the RFC, respecting feature freeze and proposing it for 7.1, or > should I just ask the PR to be merged in 7.0 ? If it is accepted by a > vote, can it still go to 7.0 ? It is really not clear to me. This RFC seems to request a change in functionality of existing function, which already does something (albeit not very useful thing). This doesn't look like self-contained change to me. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Thu, Apr 2, 2015 at 12:27 PM, Dan Ackroyd wrote: > Ferenc Kovacs wrote: > > this would also eliminate > > the confusion, that something is present in 5.6.27 but not in > > 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will > > land in 5.5.41). > > I think the solution to this is pretty clear, as Rowan put it: > > Rowan Collins wrote: > > - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug > fixes only. Thus 5.5.x should not be receiving features. > > Trying to develop several versions of PHP in parallel causes the > confusion. If users want new features there is an obvious way for them > to get them; upgrade their version of PHP. > +1 This is exactly it. The longer older versions are "supported" the longer they remain in the wild. > > Levi Morrison wrote: > > It's not just a pain to document, but there's no > > real reason to do this because we have minor releases (the Y in X.Y.Z) > > each year. > > This is only true for the past couple of years. This needs to be a > separate conversation but if we're going to continue to release a new > minor version each year, and we continue to drop support for previous > versions, it is a dramatic change to the support lifecycle for PHP. > > Getting people to upgrade from an ancient version of PHP to a much > better PHP 5.4 is acceptable as we can say that it's a much better > version of PHP. Forcing people to upgrade from 7.0 to 7.3, when it > will only be an incremental improvement is going to have much more > resistance from users. > > Because of that, I think we may feel pressure to slow down the change > in minor version numbers. I also just don't seem a problem in adding > functions in patch versions, so long as there is no BC break. > > > On 2 April 2015 at 16:23, François Laupretre wrote: > > One example : https://wiki.php.net/rfc/cyclic-replace can probably be > considered as a 'small self-contained' addition. Should I continue with the > RFC, respecting feature freeze and proposing it for 7.1, or should I just > ask the PR to be merged in 7.0 ? > > During the discussion of the RFC, several people voiced opposition to it. > > Nikita Popov wrote: > > I'm against this RFC. Not because I don't like the implementation or > > similar, I simply don't consider this functionality to be sufficiently > > important to warrant both the additional internal complexity it adds and > > the complexity it adds to our user-facing API. > > So I think this does need an RFC to allow people to vote properly. > > And yes, I think the preg_replace_callback_array addition probably > should have gone to a vote. I know some people have stated objections > about having too many RFCs - but I think that having a small hurdle to > adding stuff to core is not a bad thing. If nothing else, it forces > people to think and describe the changes clearly. > I don't see any negative to require RFC to be much more common. It promotes more communication of an addition, and also helps provide documentation to users about new features coming through as they can read the RFCs and see what's approved, rejected, in limbo, etc. > > cheers > Dan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I know I'm new to this list, and its my first response, but I feel like more transparency is a good thing for the users of PHP. Cheers! Ryan
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Ferenc Kovacs wrote: > this would also eliminate > the confusion, that something is present in 5.6.27 but not in > 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will > land in 5.5.41). I think the solution to this is pretty clear, as Rowan put it: Rowan Collins wrote: > - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug > fixes only. Thus 5.5.x should not be receiving features. Trying to develop several versions of PHP in parallel causes the confusion. If users want new features there is an obvious way for them to get them; upgrade their version of PHP. Levi Morrison wrote: > It's not just a pain to document, but there's no > real reason to do this because we have minor releases (the Y in X.Y.Z) > each year. This is only true for the past couple of years. This needs to be a separate conversation but if we're going to continue to release a new minor version each year, and we continue to drop support for previous versions, it is a dramatic change to the support lifecycle for PHP. Getting people to upgrade from an ancient version of PHP to a much better PHP 5.4 is acceptable as we can say that it's a much better version of PHP. Forcing people to upgrade from 7.0 to 7.3, when it will only be an incremental improvement is going to have much more resistance from users. Because of that, I think we may feel pressure to slow down the change in minor version numbers. I also just don't seem a problem in adding functions in patch versions, so long as there is no BC break. On 2 April 2015 at 16:23, François Laupretre wrote: > One example : https://wiki.php.net/rfc/cyclic-replace can probably be > considered as a 'small self-contained' addition. Should I continue with the > RFC, respecting feature freeze and proposing it for 7.1, or should I just ask > the PR to be merged in 7.0 ? During the discussion of the RFC, several people voiced opposition to it. Nikita Popov wrote: > I'm against this RFC. Not because I don't like the implementation or > similar, I simply don't consider this functionality to be sufficiently > important to warrant both the additional internal complexity it adds and > the complexity it adds to our user-facing API. So I think this does need an RFC to allow people to vote properly. And yes, I think the preg_replace_callback_array addition probably should have gone to a vote. I know some people have stated objections about having too many RFCs - but I think that having a small hurdle to adding stuff to core is not a bad thing. If nothing else, it forces people to think and describe the changes clearly. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
> De : Stanislav Malyshev [mailto:smalys...@gmail.com] > > > The questions here are: > > * will this code break any code running with PHP before that patch? > > * does this code change the language in any way? > > OK, so I think there's a misunderstanding here. What you describing is > exactly my position - enhancements that are a) small and b) > self-contained are OK, others are not OK. This has been the case since > we started the whole format release process thing. It seems to me we are mixing two questions : can 'small self-contained' changes be introduced in a patch release, and how 'small' and 'self-contained' a change must be not to require an RFC ? It seems implicit that, once an RFC is written, it is not a 'small self-contained' change anymore. One example : https://wiki.php.net/rfc/cyclic-replace can probably be considered as a 'small self-contained' addition. Should I continue with the RFC, respecting feature freeze and proposing it for 7.1, or should I just ask the PR to be merged in 7.0 ? If it is accepted by a vote, can it still go to 7.0 ? It is really not clear to me. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > The questions here are: > * will this code break any code running with PHP before that patch? > * does this code change the language in any way? OK, so I think there's a misunderstanding here. What you describing is exactly my position - enhancements that are a) small and b) self-contained are OK, others are not OK. This has been the case since we started the whole format release process thing. If you agree with that, then our positions are completely the same. However, it's not what Pierre's (and possibly others) position is - that position does not ask any questions, it's a blanket ban on any enhancement, without any consideration or looking into the substance of the enhancement. If it adds anything that did not exist before, however minor and safe, it is still banned. > But then using the x.y.z version schema implies something like semver No it doesn't. People used versions way before semver was even a thing, and semver does not owns versioning in any way. There are literally hundreds if not thousands of projects using this version format without any relation to semver. We may reuse the rules semver uses, when it makes sense to us, but using three-component version does not introduce any obligation to abide by what semver.org says to the letter. > Instead we should consider having a stable "PHP-next" nightly release > that is something like a stabilized master that gets all changes for the > X.Y+1 release. If you require these little features, you use that, if Who will be doing that? Who will be doing all the necessary backporting and maintenance and how it's different from just porting stable changes to stable version? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi, Am 01.04.2015 um 22:36 schrieb Stanislav Malyshev: >> Debian, Ubuntu and CentOS: ~21,23% >> >> (I assume here like Anthony that the installs matching a distribution >> specific version always come from that distribution). > > Pretty big one, I'd say, but even with this one you only get 1/5. Also, > as I said, it's very easy to take distro package and repackage it to use > the source from the same minor but up-to-date patch version. As I said, I miss-remembered the numbers to be much higher. >> An addition and a bug fix are different things. > > I know but you said, I'm quoting, "please let the x.y.z versions contain > only additional (security) fixes" which excluding non-security fixes too. I tried to indicate with braces around security that general non-security fixes may be allowed to, but I try to be more explicit next time ;-) > Let's consider a somewhat arbitrary example: > https://github.com/php/php-src/pull/1211 > > There's a HTTP status code needs to be added (doesn't matter if new or > just omitted by oversight). You could have it in next 5.6 version (you > can have it in use in 3 months realistically - one month for release to > catch up, 2 months for ops in your project to be confident that new > patch release doesn't break anything) or you could have it in 2.5 years > (1.5 years for 7.1 to be released, 1 year - and that's *extremely* > optimistic - for ops to be ok to switch to a new distro version which > hopefully - just hopefully, extremely optimistic again - but that time > ships with 7.1 and not still randomly patched 5.5). The questions here are: * will this code break any code running with PHP before that patch? * does this code change the language in any way? if any of this is true, I would consider the patch not self-contained any more. > For me, it sounds insane that you'd have to wait for so long for such a > simple thing. > > Of course, instead of status code it could be option support in XML, or > new function/option support in ICU, or new connection option in mysql. > Any improvement in the environment - do you want it in PHP in terms of > several years or in terms of 3 months? But then using the x.y.z version schema implies something like semver but in reality we have more like a rolling release. Instead we should consider having a stable "PHP-next" nightly release that is something like a stabilized master that gets all changes for the X.Y+1 release. If you require these little features, you use that, if you only require security/bug fixes, you stick to the regular x.y.z releases. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > Debian, Ubuntu and CentOS: ~21,23% > > (I assume here like Anthony that the installs matching a distribution > specific version always come from that distribution). Pretty big one, I'd say, but even with this one you only get 1/5. Also, as I said, it's very easy to take distro package and repackage it to use the source from the same minor but up-to-date patch version. > An addition and a bug fix are different things. I know but you said, I'm quoting, "please let the x.y.z versions contain only additional (security) fixes" which excluding non-security fixes too. Let's consider a somewhat arbitrary example: https://github.com/php/php-src/pull/1211 There's a HTTP status code needs to be added (doesn't matter if new or just omitted by oversight). You could have it in next 5.6 version (you can have it in use in 3 months realistically - one month for release to catch up, 2 months for ops in your project to be confident that new patch release doesn't break anything) or you could have it in 2.5 years (1.5 years for 7.1 to be released, 1 year - and that's *extremely* optimistic - for ops to be ok to switch to a new distro version which hopefully - just hopefully, extremely optimistic again - but that time ships with 7.1 and not still randomly patched 5.5). For me, it sounds insane that you'd have to wait for so long for such a simple thing. Of course, instead of status code it could be option support in XML, or new function/option support in ICU, or new connection option in mysql. Any improvement in the environment - do you want it in PHP in terms of several years or in terms of 3 months? I foresee what it would turn into is arguing "well, not supporting option X is really a bug so that's a bugfix!" which only will lead to more chaos and argument. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi Trevor, Am 01.04.2015 um 22:19 schrieb Trevor Suarez: > Author of PR https://github.com/php/php-src/pull/1145 here. > > I'm really quite sorry. I didn't mean to create a mess here. I was just > trying to contribute. :/ I am sorry I caused this mess by using your PR (or better: the acceptance of it without noticing the internals thread regarding it) as an example. I hope this does not prevent you from contributing in the future. > Unfortunately, whether or not an RFC was necessary for an addition like > this wasn't very clear. I'm an internals noob, so I simply tried to follow > the flow of the addition of the similar method > `DateTimeImmutable::createFromMutable()` that was added, without RFC > (correct me if I'm wrong), in 5.6.0: > http://php.net/manual/en/datetimeimmutable.createfrommutable.php I think DateTimeInterface and DateTimeImmutable where added in 5.6, but I don't know if there was some RFC for that, I did not follow the internals list back then. > Unfortunately, I'm not a huge fan of Derick's `createFromMutable()` method > (why isn't there just a `createFromInstance()` or `copy()` method of some > sort), but I tried to best follow the current design with my proposal and > pull request. I would really like you to create an RFC that uses a single method in the DateTimeInterface for this kind of cloning. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Damn Gmail... I just top-posted. I'm going to go away for a while now... On Wed, Apr 1, 2015 at 4:19 PM Trevor Suarez wrote: > Author of PR https://github.com/php/php-src/pull/1145 here. > > I'm really quite sorry. I didn't mean to create a mess here. I was just > trying to contribute. :/ > > Unfortunately, whether or not an RFC was necessary for an addition like > this wasn't very clear. I'm an internals noob, so I simply tried to follow > the flow of the addition of the similar method > `DateTimeImmutable::createFromMutable()` that was added, without RFC > (correct me if I'm wrong), in 5.6.0: > http://php.net/manual/en/datetimeimmutable.createfrommutable.php > > Unfortunately, I'm not a huge fan of Derick's `createFromMutable()` > method (why isn't there just a `createFromInstance()` or `copy()` method of > some sort), but I tried to best follow the current design with my proposal > and pull request. > > I think some clarification regarding what does or does-not require an RFC > would make it much more helpful to contributors that want to help build PHP. > > Again, sorry if I caused any issue here. > > - Trevor > > On Wed, Apr 1, 2015 at 4:09 PM Dennis Birkholz > wrote: > >> Hi, >> >> Am 01.04.2015 um 21:43 schrieb Stanislav Malyshev: >> >> That is right and I think that is the reality we have to face: most >> >> users use distro versions. They get a new version when they need to >> >> upgrade their distro every few years. >> > >> > I'm not sure where you got this statistics from, but as I said, it is >> > very easy to make .rpm or .deb with source version from php.net of the >> > same minor. I've seen it done many times. It's next to impossible to >> > make the same with different major, and nobody would do it for obvious >> > stability concerns. I think the approach of "you have to wait several >> > years for any tiny change" is terrible and detrimental for PHP >> > development, however easy it makes the life of folks in Debian, etc. >> >> I vaguely remembered the usage statistics that Anthony assembled in >> December and had other numbers in my head. (see >> http://blog.ircmaxell.com/2014/12/php-install-statistics.html) >> >> 5.5.12 (Ubuntu 14.10): 0.16% >> 5.5.9 (Ubuntu 14.04): 1.81% >> 5.4.16 (CentOS 7.0): 0.42% >> 5.4.4 (Debian Wheezy): 2.14% >> 5.3.10 (Ubuntu 12.04): 4.13% >> 5.3.3 (Debian Squeeze, Centos 6.6): 10.37% >> 5.3.2 (Ubuntu 10.04): 1.06% >> 5.1.6 (CentOS 5.11): 1.14% >> == >> Debian, Ubuntu and CentOS: ~21,23% >> >> (I assume here like Anthony that the installs matching a distribution >> specific version always come from that distribution). >> >> So I have to step a little back from my previous statement, only about >> 1/5th of the installs seem to use distribution installs. But there are a >> lot of used versions in between. Why they don't upgrade I don't know, >> but if the upgrade would be a no-brainer without any risk for >> incompatibility, probably more would upgrade, but that is just >> speculation. >> >> >> No, I don't say ban non-security bugfixes. But I say don't add new >> >> methods/functionality that should go in the next feature release. >> > >> > I'm fine with adding only those that should go into the current one, >> > namely small self-contained additions :) Just as we agreed on long ago. >> >> An addition and a bug fix are different things. >> >> Greets >> Dennis >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Author of PR https://github.com/php/php-src/pull/1145 here. I'm really quite sorry. I didn't mean to create a mess here. I was just trying to contribute. :/ Unfortunately, whether or not an RFC was necessary for an addition like this wasn't very clear. I'm an internals noob, so I simply tried to follow the flow of the addition of the similar method `DateTimeImmutable::createFromMutable()` that was added, without RFC (correct me if I'm wrong), in 5.6.0: http://php.net/manual/en/datetimeimmutable.createfrommutable.php Unfortunately, I'm not a huge fan of Derick's `createFromMutable()` method (why isn't there just a `createFromInstance()` or `copy()` method of some sort), but I tried to best follow the current design with my proposal and pull request. I think some clarification regarding what does or does-not require an RFC would make it much more helpful to contributors that want to help build PHP. Again, sorry if I caused any issue here. - Trevor On Wed, Apr 1, 2015 at 4:09 PM Dennis Birkholz wrote: > Hi, > > Am 01.04.2015 um 21:43 schrieb Stanislav Malyshev: > >> That is right and I think that is the reality we have to face: most > >> users use distro versions. They get a new version when they need to > >> upgrade their distro every few years. > > > > I'm not sure where you got this statistics from, but as I said, it is > > very easy to make .rpm or .deb with source version from php.net of the > > same minor. I've seen it done many times. It's next to impossible to > > make the same with different major, and nobody would do it for obvious > > stability concerns. I think the approach of "you have to wait several > > years for any tiny change" is terrible and detrimental for PHP > > development, however easy it makes the life of folks in Debian, etc. > > I vaguely remembered the usage statistics that Anthony assembled in > December and had other numbers in my head. (see > http://blog.ircmaxell.com/2014/12/php-install-statistics.html) > > 5.5.12 (Ubuntu 14.10): 0.16% > 5.5.9 (Ubuntu 14.04): 1.81% > 5.4.16 (CentOS 7.0): 0.42% > 5.4.4 (Debian Wheezy): 2.14% > 5.3.10 (Ubuntu 12.04): 4.13% > 5.3.3 (Debian Squeeze, Centos 6.6): 10.37% > 5.3.2 (Ubuntu 10.04): 1.06% > 5.1.6 (CentOS 5.11): 1.14% > == > Debian, Ubuntu and CentOS: ~21,23% > > (I assume here like Anthony that the installs matching a distribution > specific version always come from that distribution). > > So I have to step a little back from my previous statement, only about > 1/5th of the installs seem to use distribution installs. But there are a > lot of used versions in between. Why they don't upgrade I don't know, > but if the upgrade would be a no-brainer without any risk for > incompatibility, probably more would upgrade, but that is just speculation. > > >> No, I don't say ban non-security bugfixes. But I say don't add new > >> methods/functionality that should go in the next feature release. > > > > I'm fine with adding only those that should go into the current one, > > namely small self-contained additions :) Just as we agreed on long ago. > > An addition and a bug fix are different things. > > Greets > Dennis > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Wed, Apr 1, 2015 at 9:38 PM, Stanislav Malyshev wrote: > Hi! > > > As I mentioned this wasn't something without precedence, but seeing how > > Derick(ext/date lead author/maintainer) was explicitly against this > > change, and there were no favorable response from the list I tend to > > agree with the revert. > > Derick reviewed that patch and I didn't see him even mentioning he is > explicitly against. Could you point me to where he describes he is > against it? If you think it needs to be reverted please do so, you are > the 5.6 RM. If you want me to do it I can do it later (on the weekend) > but you'll have to update the RC branch. > > you already stated that you missed Derick's mail, so I won't comment on that, but only the revert part: I'm able and willing to revert stuff when needed, but I always assume good faith (and that was the case here) and prefer contacting the author first if there is time pressure to revert. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi, Am 01.04.2015 um 21:43 schrieb Stanislav Malyshev: >> That is right and I think that is the reality we have to face: most >> users use distro versions. They get a new version when they need to >> upgrade their distro every few years. > > I'm not sure where you got this statistics from, but as I said, it is > very easy to make .rpm or .deb with source version from php.net of the > same minor. I've seen it done many times. It's next to impossible to > make the same with different major, and nobody would do it for obvious > stability concerns. I think the approach of "you have to wait several > years for any tiny change" is terrible and detrimental for PHP > development, however easy it makes the life of folks in Debian, etc. I vaguely remembered the usage statistics that Anthony assembled in December and had other numbers in my head. (see http://blog.ircmaxell.com/2014/12/php-install-statistics.html) 5.5.12 (Ubuntu 14.10): 0.16% 5.5.9 (Ubuntu 14.04): 1.81% 5.4.16 (CentOS 7.0): 0.42% 5.4.4 (Debian Wheezy): 2.14% 5.3.10 (Ubuntu 12.04): 4.13% 5.3.3 (Debian Squeeze, Centos 6.6): 10.37% 5.3.2 (Ubuntu 10.04): 1.06% 5.1.6 (CentOS 5.11): 1.14% == Debian, Ubuntu and CentOS: ~21,23% (I assume here like Anthony that the installs matching a distribution specific version always come from that distribution). So I have to step a little back from my previous statement, only about 1/5th of the installs seem to use distribution installs. But there are a lot of used versions in between. Why they don't upgrade I don't know, but if the upgrade would be a no-brainer without any risk for incompatibility, probably more would upgrade, but that is just speculation. >> No, I don't say ban non-security bugfixes. But I say don't add new >> methods/functionality that should go in the next feature release. > > I'm fine with adding only those that should go into the current one, > namely small self-contained additions :) Just as we agreed on long ago. An addition and a bug fix are different things. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > And Derick wrote: (in http://markmail.org/message/ukwizupev32ld5tg) > "I am against this addition, even though the patch looks OK." That is > not "any objection from him except for small CS fixes" but I don't know > what discussion happened off-list. OK, I missed that one. I'll revert it then. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > That is right and I think that is the reality we have to face: most > users use distro versions. They get a new version when they need to > upgrade their distro every few years. I'm not sure where you got this statistics from, but as I said, it is very easy to make .rpm or .deb with source version from php.net of the same minor. I've seen it done many times. It's next to impossible to make the same with different major, and nobody would do it for obvious stability concerns. I think the approach of "you have to wait several years for any tiny change" is terrible and detrimental for PHP development, however easy it makes the life of folks in Debian, etc. > No, I don't say ban non-security bugfixes. But I say don't add new > methods/functionality that should go in the next feature release. I'm fine with adding only those that should go into the current one, namely small self-contained additions :) Just as we agreed on long ago. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > As I mentioned this wasn't something without precedence, but seeing how > Derick(ext/date lead author/maintainer) was explicitly against this > change, and there were no favorable response from the list I tend to > agree with the revert. Derick reviewed that patch and I didn't see him even mentioning he is explicitly against. Could you point me to where he describes he is against it? If you think it needs to be reverted please do so, you are the 5.6 RM. If you want me to do it I can do it later (on the weekend) but you'll have to update the RC branch. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi Stas, Am 01.04.2015 um 21:19 schrieb Stanislav Malyshev: > Hi! > >> I am sorry for the contributor but my example is >> https://github.com/php/php-src/pull/1145 >> (DateTime::createFromImmutable() method) which was posted here on the >> list, got three negative replies but was merged nevertheless. I will not >> reproduce the arguments here but now the door for a clean solution >> inside the DateTimeInterface seems closed forever. > > Why is it closed forever? I've seen Derick look at the patch and didn't > see any objection from him except for small CS fixes. Also, we did not > release it yet so if there's any problem with it it still can be > reverted. But I haven't seen any mention of it so far on the list except > for this mention in completely unrelated topic which would be extremely > easy to miss and that says basically "all is lost now, no use to discuss > it, the end is nigh" without explaining anything. If you want to explain > yourself, please start a topic and do this, we have 2 weeks before > 5.6.8, ample time to revert if necessary. the discussion appeared on the list at the 5th of march: http://markmail.org/message/3aesaaoqv6ihiw53 The thing with this patch is, there should be one factory method for each classes implementing DateTimeInterface to create an instance from any other instance of DateTimeInterface. Having some factory methods for some reference objects is just inconsistent. And Derick wrote: (in http://markmail.org/message/ukwizupev32ld5tg) "I am against this addition, even though the patch looks OK." That is not "any objection from him except for small CS fixes" but I don't know what discussion happened off-list. >> Besides, I think that the vast majority of PHP users out there is using >> distro versions, so it does not matter to them if a feature goes into >> 5.6.7 oder 7.1.0, they will get the feature when the distro upgrades. > > That'd basically mean "never", no distro would go from 5.6 to 7.1 within > the same version, and changing distro version is insanely operationally > complex thing which is done very rarely. That is right and I think that is the reality we have to face: most users use distro versions. They get a new version when they need to upgrade their distro every few years. >> So, please let the x.y.z versions contain only additional (security) >> fixes and stick to the RFC process, thanks. > > We are already doing this. The discussion is about changing the process > to ban enhancements in released versions, which was never the case and > we specifically emphasized this when we started it. Now you seem to > propose to ban non-security bugfixes on releases too. So basically you'd > have to wait for years to even get a bug fixed. Nice. No, I don't say ban non-security bugfixes. But I say don't add new methods/functionality that should go in the next feature release. Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > I am sorry for the contributor but my example is > https://github.com/php/php-src/pull/1145 > (DateTime::createFromImmutable() method) which was posted here on the > list, got three negative replies but was merged nevertheless. I will not > reproduce the arguments here but now the door for a clean solution > inside the DateTimeInterface seems closed forever. Why is it closed forever? I've seen Derick look at the patch and didn't see any objection from him except for small CS fixes. Also, we did not release it yet so if there's any problem with it it still can be reverted. But I haven't seen any mention of it so far on the list except for this mention in completely unrelated topic which would be extremely easy to miss and that says basically "all is lost now, no use to discuss it, the end is nigh" without explaining anything. If you want to explain yourself, please start a topic and do this, we have 2 weeks before 5.6.8, ample time to revert if necessary. > Besides, I think that the vast majority of PHP users out there is using > distro versions, so it does not matter to them if a feature goes into > 5.6.7 oder 7.1.0, they will get the feature when the distro upgrades. That'd basically mean "never", no distro would go from 5.6 to 7.1 within the same version, and changing distro version is insanely operationally complex thing which is done very rarely. > So, please let the x.y.z versions contain only additional (security) > fixes and stick to the RFC process, thanks. We are already doing this. The discussion is about changing the process to ban enhancements in released versions, which was never the case and we specifically emphasized this when we started it. Now you seem to propose to ban non-security bugfixes on releases too. So basically you'd have to wait for years to even get a bug fixed. Nice. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi, On Wed, Apr 1, 2015 at 6:15 PM, Michael Wallner wrote: > > > On 01 04 2015, at 18:28, François Laupretre wrote: > > > >> De : Ferenc Kovacs [mailto:tyr...@gmail.com] > >> > >> I could accept any decision between holding off new features until next > >> minor/major and allowing features explicitly without going through an > RFC, but I > >> want to have an explicit definition on what is allowed and how should > the case- > >> by-case process work. > > > > The release process document is clear : "New features or additions to > the core should go through the RFC process." (hopefully considering the > 'core' as the whole PHP distribution). It would be better using "must" > instead of "should" but it is quite clear. > > > > So, providing "a room for exceptions on a case by case basis and only > for small self-contained features and additions" does not mean that these > features don't have to go through an RFC. There is nothing to add to the > rules, we just need to have them enforced by people who currently merge new > features without demanding an approved RFC. If everyone respects the rules, > the 'case by case process' is clear, it means 'approved through an RFC'. > Only bug fixes with no side effect can be merged without an RFC. > > > > So, once again, as https://github.com/php/php-src/pull/1145 clearly did > not follow the rules and was not approved in any way, I'm asking whoever > merged it to revert the change and ask the author to go through an RFC. > > It’s not a secret that I’m not a big fan of too much bureaucracy, we’re > still humans that can discuss and argue without a formal RFC. > If anything develops to be controversial, let’s go through an RFC, if not, > then fine and let them go ahead. > > I agree here. I think that we should definitely email to the internals about any small addition (self-contained constant or function) and if there are no objection and everyone agrees that it's a good idea, then I don't think we need RFC. Cheers Jakub
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Tue, Mar 31, 2015 at 9:44 PM, Rowan Collins wrote: > On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev < > smalys...@gmail.com> wrote: > >> This is a straw man as far as the points I made are concerned. I'm > >> talking about the risk of switching from 5.5 to 5.6, which is pretty > >low. > > > >Switching to 5.6 would be useless since what is being propose it to ban > >any enhancements up to 7.1. > > Proposed by whom? The only mentions of 7.1 I've spotted have been from > you, which is why I called it a straw man. > > So, rather than arguing round in circles, here's what I would propose: > > - Up until the first release candidate of x.y.0, small features can be > added to both the most recent live branch and the new branch being prepared > for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and > 7.1-pre). > - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug > fixes only. Thus 5.5.x should not be receiving features. > - As an exception to the above, when releasing x.0.0, the previous branch > may continue receiving small features, until it reaches the end of its > "active support" phase. In other words, keep backporting things to 5.6.x > after 7.0.0 is released, since adoption of the latter is likely to be slow. > By the time 7.1.0 comes around, active support for 5.6 will have ended > anyway, unless we make some other exception to the normal process. > > This is very much a compromise between the SemVer ideal of a patch > release, and the practical implications of a yearly release cycle. The aim > is to make it obvious to users what they'll get in return for upgrading, > and to smoothly transition a branch from "cutting edge" to "stable with bug > fixes", then to "security only" and "end of life". > > What do people think? > +1
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Wed, Apr 1, 2015 at 6:28 PM, François Laupretre wrote: > > De : Ferenc Kovacs [mailto:tyr...@gmail.com] > > > > I could accept any decision between holding off new features until next > > minor/major and allowing features explicitly without going through an > RFC, but I > > want to have an explicit definition on what is allowed and how should > the case- > > by-case process work. > > The release process document is clear : "New features or additions to the > core should go through the RFC process." (hopefully considering the 'core' > as the whole PHP distribution). It would be better using "must" instead of > "should" but it is quite clear. > I see your point, but the consensus/status quo(based on past mailing list discussion and( is/was that not everything requires an RFC. > > So, providing "a room for exceptions on a case by case basis and only for > small self-contained features and additions" does not mean that these > features don't have to go through an RFC. There is nothing to add to the > rules, we just need to have them enforced by people who currently merge new > features without demanding an approved RFC. If everyone respects the rules, > the 'case by case process' is clear, it means 'approved through an RFC'. > Only bug fixes with no side effect can be merged without an RFC. > again, I'm fine with changing the current status quo, but we can't pretend that this was always the consensus when we were doing otherwise and >95% of the people seemed to be okay with it (I had a couple of threads in the past years where I tried to clarify a couple of things about the voting and releaseprocess rfcs, but nothing really come out of it). > > So, once again, as https://github.com/php/php-src/pull/1145 clearly did > not follow the rules and was not approved in any way, I'm asking whoever > merged it to revert the change and ask the author to go through an RFC. > As I mentioned this wasn't something without precedence, but seeing how Derick(ext/date lead author/maintainer) was explicitly against this change, and there were no favorable response from the list I tend to agree with the revert. For the record this was merged by Stas: http://git.php.net/?p=php-src.git;a=commitdiff;h=cc2fd00942d59975326166be70cd36da85a681d3 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
> On 01 04 2015, at 18:28, François Laupretre wrote: > >> De : Ferenc Kovacs [mailto:tyr...@gmail.com] >> >> I could accept any decision between holding off new features until next >> minor/major and allowing features explicitly without going through an RFC, >> but I >> want to have an explicit definition on what is allowed and how should the >> case- >> by-case process work. > > The release process document is clear : "New features or additions to the > core should go through the RFC process." (hopefully considering the 'core' as > the whole PHP distribution). It would be better using "must" instead of > "should" but it is quite clear. > > So, providing "a room for exceptions on a case by case basis and only for > small self-contained features and additions" does not mean that these > features don't have to go through an RFC. There is nothing to add to the > rules, we just need to have them enforced by people who currently merge new > features without demanding an approved RFC. If everyone respects the rules, > the 'case by case process' is clear, it means 'approved through an RFC'. Only > bug fixes with no side effect can be merged without an RFC. > > So, once again, as https://github.com/php/php-src/pull/1145 clearly did not > follow the rules and was not approved in any way, I'm asking whoever merged > it to revert the change and ask the author to go through an RFC. It’s not a secret that I’m not a big fan of too much bureaucracy, we’re still humans that can discuss and argue without a formal RFC. If anything develops to be controversial, let’s go through an RFC, if not, then fine and let them go ahead. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
> De : Ferenc Kovacs [mailto:tyr...@gmail.com] > > I could accept any decision between holding off new features until next > minor/major and allowing features explicitly without going through an RFC, > but I > want to have an explicit definition on what is allowed and how should the > case- > by-case process work. The release process document is clear : "New features or additions to the core should go through the RFC process." (hopefully considering the 'core' as the whole PHP distribution). It would be better using "must" instead of "should" but it is quite clear. So, providing "a room for exceptions on a case by case basis and only for small self-contained features and additions" does not mean that these features don't have to go through an RFC. There is nothing to add to the rules, we just need to have them enforced by people who currently merge new features without demanding an approved RFC. If everyone respects the rules, the 'case by case process' is clear, it means 'approved through an RFC'. Only bug fixes with no side effect can be merged without an RFC. So, once again, as https://github.com/php/php-src/pull/1145 clearly did not follow the rules and was not approved in any way, I'm asking whoever merged it to revert the change and ask the author to go through an RFC. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Wed, Apr 1, 2015 at 1:23 PM, François Laupretre wrote: > > De : Dennis Birkholz [mailto:den...@birkholz.biz] > > > > in my opinion all feature changes should go in the next X.Y version and > > should require an RFC. > > The reason is that "small self-contained changes" that get pulled in > > without a discussion on internals and an RFC can easily lead to bad > > design decisions in the long run. > > Correct. The "small self-contained changes" concept easily leads to the > rules not being the same for everyone. > this is what I feel, and one of the reasons for starting this thread. > > > I am sorry for the contributor but my example is > > https://github.com/php/php-src/pull/1145 > > (DateTime::createFromImmutable() method) which was posted here on the > > list, got three negative replies but was merged nevertheless. I will not > > reproduce the arguments here but now the door for a clean solution > > inside the DateTimeInterface seems closed forever. > > This example is clearly an RFC released as a PR to bypass the rules > (discussion, vote, and feature freeze date). I don't understand why it was > accepted and merged. Can someone give the rule that was followed in this > case ? If it should have gone through an RFC, can we revert the change and > send him back to the RFC process ? > > https://wiki.php.net/rfc/releaseprocess "No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis." "Bugfixes only (with a room for exceptions on a case by case basis and only for small self contained features additions)." The problem is that there is no definition/explanation for the case-by-case basis. Does it need a vote? Does it need prior discussion on the thread? Does it need explicit approval from the RMs? This problem was brought up in the past a couple of times (the releaseprocess RFC being too vague here and there also this specific issue about not having an agreed upon workflow for the approval process for micro versions), but no resolution was reached so there are examples where we have lengthly discussion and fullblown RFC for adding a new constant option to json_encode() while some other feature request just gets merged by an RM or maintainer of that given extension. I could accept any decision between holding off new features until next minor/major and allowing features explicitly without going through an RFC, but I want to have an explicit definition on what is allowed and how should the case-by-case process work. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
RE: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
> De : Dennis Birkholz [mailto:den...@birkholz.biz] > > in my opinion all feature changes should go in the next X.Y version and > should require an RFC. > The reason is that "small self-contained changes" that get pulled in > without a discussion on internals and an RFC can easily lead to bad > design decisions in the long run. Correct. The "small self-contained changes" concept easily leads to the rules not being the same for everyone. > I am sorry for the contributor but my example is > https://github.com/php/php-src/pull/1145 > (DateTime::createFromImmutable() method) which was posted here on the > list, got three negative replies but was merged nevertheless. I will not > reproduce the arguments here but now the door for a clean solution > inside the DateTimeInterface seems closed forever. This example is clearly an RFC released as a PR to bypass the rules (discussion, vote, and feature freeze date). I don't understand why it was accepted and merged. Can someone give the rule that was followed in this case ? If it should have gone through an RFC, can we revert the change and send him back to the RFC process ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hello, Am 30.03.2015 um 12:04 schrieb Ferenc Kovacs: > I know that our official release process allows that, but there are some > reasonable arguments against doing that and this topic was brought up > multiple times related to specific fixes. > I have two open PRs like that: > https://github.com/php/php-src/pull/1204 > https://github.com/php/php-src/pull/969 > and of course there are a bunch of similar ones from other people, and > there are cases when somebody simply pushes a change like that, other times > somebody points out that it should require an RFC( > https://wiki.php.net/rfc/json_preserve_fractional_part for example), but > most of the times we simply don't know what to do, and eventually we just > let the PR/patch to rot and die. > I would like to know if we can come up with a rule which can have consensus > behind it, and maybe formalize it as an extension to our current > releaseprocess rfc. in my opinion all feature changes should go in the next X.Y version and should require an RFC. The reason is that "small self-contained changes" that get pulled in without a discussion on internals and an RFC can easily lead to bad design decisions in the long run. I am sorry for the contributor but my example is https://github.com/php/php-src/pull/1145 (DateTime::createFromImmutable() method) which was posted here on the list, got three negative replies but was merged nevertheless. I will not reproduce the arguments here but now the door for a clean solution inside the DateTimeInterface seems closed forever. Besides, I think that the vast majority of PHP users out there is using distro versions, so it does not matter to them if a feature goes into 5.6.7 oder 7.1.0, they will get the feature when the distro upgrades. But for the distro package maintainers and the users it would be a lot easier if e.g. the debian version could just be the latest patch version and not a mix of several versions after their package freeze. So, please let the x.y.z versions contain only additional (security) fixes and stick to the RFC process, thanks. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Wed, Apr 1, 2015 at 1:28 PM, Stanislav Malyshev wrote: > Hi! > >> That one is rather easy to follow and disallow any kind of bully pushes. > > "Easy to follow" != "good to follow". I have no idea what you mean by > "bully pushes". > >> Which years are you referring to? > > The ones that will pass between feature being contributed (which if > enhancements are banned in released versions will have to go into 7.1 > once 7.0 hits release cycle, which is very close to now, arguably > already happening) and the version containing the feature (that being > 7.1 as per above) is available to the contributor for their project. > Note it's not the same as "released on php.net" as upgrades take > significant time to propagate, see 1% of 5.6 adoption. Optimistically, > the delta between 7.0 and 7.1 is at least a year, and since wide > adoption of 7.1 is not likely to happen in less than a year, thus plural > "years". > >> with a couple of maintainers (of these distros) and they all like this >> new process and would like even more strictness when it comes to new >> features. Why? Because it makes their work easier, be testing, >> validating a new release for a LTS, etc. > > I value their effort a lot, but with all due respect I'm sorry to say > that their work being easier is a lower priority than PHP being better > for the users. How many % use source install vs packages? From which users are we talking about here? > If the choice is between us working harder but PHP being > better and us working less but PHP being worse, then we should choose to > work harder. Same should apply to the middlemen between us and the > users. So I can not accept the argument of "let's ban new features from > PHP until 7.1 because it makes it easier to repackage PHP". I'd be glad > to make their work easier, but not at the cost of hurting the whole > project. It is one of many arguments. Do not forget the other ones, which are as valid and important than the distros one. >> So what you are saying is that now we are on track to actually improve >> new releases adoption we should not make it even easier? Or go > > In general, we should definitely make it easier. However, what you are > proposing is not a good way to achieve it. It's actually a terrible way > to do it, as it kills all motivation for small-scale participation and > also decreases motivation to run latest stable version for people that > need some small thing that is added only recently. Since they can't have > it in realistic timeframe, they'd work around it and since they have > already worked around it, it no longer motivates them to upgrade. What killed it was to reject 5.7, this was a mistake based on nothing but some random fears about not being able to finish 7 "in time". To make 5.6 the "all in" small features improvements in every 2nd patch releases for the next year is going to be good fun, for everyone. Remember? 3 years, that means we have a year to get all possible small improvements in. It cannot end well imho :) >> You brought the "even longer with 7" argument, 5.7 could have >> prevented you for having to wait "years" to get one minor features or >> another. That's all. > > It would not help any, as you would ban adding small enhancements to 5.7 > either (and, if I understood it correctly, 5.7 is to be 5.6 plus BC > fixes anyway), so 5.7 would be useless if I wanted to have enhancement > that might be introduced now, since, per your philosophy, 5.6 is closed > for enhancements, 5.7 is closed too since it's 5.6 + BC fixes, and 7.0 > will be closed as soon as it enters release cycle, which is pretty much > any moment now. So if you want to add something like option to > json_decode, your first chance to have it is still 7.1. I was against not having 5.7, and against 5.7 only for notices (sadly the RFC did not contain any other options despite agreements on that). My reasoning back then and this discussion proves it correct, is that we will make a mess of 5.6 because "7 adoption will be even slower". Solving zero of these issues but making 7.x adoption even slower and 5.6.x a features check mess. Not my idea of simplicity or not the best way to increase adoption by helping users and packagers/distros. >> Chicken-egg problem, wait until people actually moves away from old >> Debian/RHEL and adopt recent ones. This is what I am saying since long >> and in the previous paragraph. Please at least try to see that. > > No, what you were saying you want to ban enhancements now (unless I > misunderstand you, then please clarify it) - not in indefinite point in > the future when our last stable adoption is not 1% but much better. When > that happens - and I hope it does, but it did not happen yet - then we > come back to this and banning enhancements in released versions and can > have the discussions with facts available then. You may think if we ban > enhancement then people would jump to 7.x in droves - but I have yet to > see anybody taking decisions thi
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 01/04/15 07:28, Stanislav Malyshev wrote: > You may think if we ban > enhancement then people would jump to 7.x in droves - but I have yet to > see anybody taking decisions this way. So far statistics says people > still are in 5.3 and 5.4 massively - though we do not add features there > for quite some time. So it doesn't look like not adding features makes > people to move on. Practical example. I still have several sites on 5.2 hosting. They need upgrading before they will run on 5.4 ... and while they would work on 5.3 with warnings switched off there is no point making that switch. They HAVE to be modified for 5.4, and that takes time :( Retesting all of the 5.4 stuff on a later version will wait until everything is on 5.4! None of these 'small self-contained additions' have any use in maintaining the existing sites, and so there is little point even bothering with 5.5 or 5.6 if 7.0 is going to be out before the last of the 5.2 sites have been upgraded. Hence my development server having both 5.4 and 7.0 running in parallel. Yes 5.6-latest is a third option on that but only until 7.0 IS released. Th switch to 7.0 will not be because of the 'new additions'. Even type hinting will only be a hindrance to be lived with rather than a 'must have' feature simply because it does nothing to help the real problems of data validation! That code is already present and working. The ONLY reason for moving forward is to keep what is currently working perfectly on 5.2 still working on a later version. Renaming everything to some new standard gives nothing but restoring the performance improvements that eaccelerator currently provides is another holding up a move from 5.4 ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > That one is rather easy to follow and disallow any kind of bully pushes. "Easy to follow" != "good to follow". I have no idea what you mean by "bully pushes". > Which years are you referring to? The ones that will pass between feature being contributed (which if enhancements are banned in released versions will have to go into 7.1 once 7.0 hits release cycle, which is very close to now, arguably already happening) and the version containing the feature (that being 7.1 as per above) is available to the contributor for their project. Note it's not the same as "released on php.net" as upgrades take significant time to propagate, see 1% of 5.6 adoption. Optimistically, the delta between 7.0 and 7.1 is at least a year, and since wide adoption of 7.1 is not likely to happen in less than a year, thus plural "years". > with a couple of maintainers (of these distros) and they all like this > new process and would like even more strictness when it comes to new > features. Why? Because it makes their work easier, be testing, > validating a new release for a LTS, etc. I value their effort a lot, but with all due respect I'm sorry to say that their work being easier is a lower priority than PHP being better for the users. If the choice is between us working harder but PHP being better and us working less but PHP being worse, then we should choose to work harder. Same should apply to the middlemen between us and the users. So I can not accept the argument of "let's ban new features from PHP until 7.1 because it makes it easier to repackage PHP". I'd be glad to make their work easier, but not at the cost of hurting the whole project. > So what you are saying is that now we are on track to actually improve > new releases adoption we should not make it even easier? Or go In general, we should definitely make it easier. However, what you are proposing is not a good way to achieve it. It's actually a terrible way to do it, as it kills all motivation for small-scale participation and also decreases motivation to run latest stable version for people that need some small thing that is added only recently. Since they can't have it in realistic timeframe, they'd work around it and since they have already worked around it, it no longer motivates them to upgrade. > You brought the "even longer with 7" argument, 5.7 could have > prevented you for having to wait "years" to get one minor features or > another. That's all. It would not help any, as you would ban adding small enhancements to 5.7 either (and, if I understood it correctly, 5.7 is to be 5.6 plus BC fixes anyway), so 5.7 would be useless if I wanted to have enhancement that might be introduced now, since, per your philosophy, 5.6 is closed for enhancements, 5.7 is closed too since it's 5.6 + BC fixes, and 7.0 will be closed as soon as it enters release cycle, which is pretty much any moment now. So if you want to add something like option to json_decode, your first chance to have it is still 7.1. > No comment. Pointless troll. I am the one keep saying that I do not > like us using only WP to validate changes. Yet you did use it as an argument, and call me a troll for pointing it out. This is just rude. > Chicken-egg problem, wait until people actually moves away from old > Debian/RHEL and adopt recent ones. This is what I am saying since long > and in the previous paragraph. Please at least try to see that. No, what you were saying you want to ban enhancements now (unless I misunderstand you, then please clarify it) - not in indefinite point in the future when our last stable adoption is not 1% but much better. When that happens - and I hope it does, but it did not happen yet - then we come back to this and banning enhancements in released versions and can have the discussions with facts available then. You may think if we ban enhancement then people would jump to 7.x in droves - but I have yet to see anybody taking decisions this way. So far statistics says people still are in 5.3 and 5.4 massively - though we do not add features there for quite some time. So it doesn't look like not adding features makes people to move on. > A blanket statement? We discussed that many times already, my stance > did not change a single yota since then. I repeated it here once again > to make it clear, and for the record. Saying something many times is not the same as substantiating it. In the last letter you did finally bring an argument for banning enhacements - it makes the life of third-party packagers easier. It is completely true, but it carries a very high price, and we should not pay this price. I'm all for any effort that makes their lives easier, but with the condition that it does not mean something as drastic as not allowing small enhancements, which was always allowed since we started the whole release process thing. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/uns
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! >> - Up until the first release candidate of x.y.0, small features can be > added to both the most recent live branch and the new branch being > prepared for release (so, right now, 5.6.x and 7.0-pre; next summer, > 7.0.x and 7.1-pre). >> - Once a new x.y.0 release is ready, x.y-1.z releases should receive > bug fixes only. Thus 5.5.x should not be receiving features. >> - As an exception to the above, when releasing x.0.0, the previous > branch may continue receiving small features, until it reaches the end > of its "active support" phase. In other words, keep backporting things > to 5.6.x after 7.0.0 is released, since adoption of the latter is likely > to be slow. By the time 7.1.0 comes around, active support for 5.6 will > have ended anyway, unless we make some other exception to the normal > process. This looks like a reasonable compromise. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Am 31.03.2015 22:45 schrieb "Rowan Collins" : > > - Up until the first release candidate of x.y.0, small features can be added to both the most recent live branch and the new branch being prepared for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and 7.1-pre). > - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug fixes only. Thus 5.5.x should not be receiving features. > - As an exception to the above, when releasing x.0.0, the previous branch may continue receiving small features, until it reaches the end of its "active support" phase. In other words, keep backporting things to 5.6.x after 7.0.0 is released, since adoption of the latter is likely to be slow. By the time 7.1.0 comes around, active support for 5.6 will have ended anyway, unless we make some other exception to the normal process. > > This is very much a compromise between the SemVer ideal of a patch release, and the practical implications of a yearly release cycle. The aim is to make it obvious to users what they'll get in return for upgrading, and to smoothly transition a branch from "cutting edge" to "stable with bug fixes", then to "security only" and "end of life". > > What do people think? That sounds very reasonable, and would suit me fine :) One issue that I think speaks for such an approach, is giving new-small-features better exposure outside of developer circles. If features only ever go into the-next-tree, they won't be seen and tried out in the field until after that is committed as a new-stable release. The feature also probably can't be added to the php.net documentation until that release happens (right). Lots less eyes seeing it, finding problems with it that might be rectified before next-becomes-stable. I think there's a three layer hierarchy of adoption at play here, which also can explain the low adoption figures of newest-stable. At the top, you have next-stable, which will be visible almost exclusively to contributors, and won't get any real world production exposure at all. Then you have the current stable, which is used by shops (like mine...) that care about building their own binaries, and that have a rather homogenous inhouse codebase that can evolve to use new major and minor features in production. And then there's the vast field which runs on distribution builds, which seems to sit on the oldest supported stable version in existence until it's faded out, and which doesn't care about new features at all. Do I make sense? :) best regards Patrick
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
hi, ps: please keep the "xyz wrote", makes harder to read your replies without it On Wed, Apr 1, 2015 at 2:57 AM, Stanislav Malyshev wrote: > Hi! > >> The problem is always a definition question, a very subjective question. > > Fortunately, we can discuss it, we're not limited to blindly following > predefined set of rules. That one is rather easy to follow and disallow any kind of bully pushes. >> I do not really buy the "I am stuck with x.y" as one has the same >> problem already. And he has barely a 2 years window to add them. > > No, right now you can add small enhancements to 5.5/5.6 and get it in > production in terms of months, not several years. Which years are you referring to? Let put things back in perspective: Since we introduced the release process RFC, more or less followed correctly but lately, distributions adopt latest PHP releases much faster. See Fedora, Debian and Ubuntu for example. I have discussed it with a couple of maintainers (of these distros) and they all like this new process and would like even more strictness when it comes to new features. Why? Because it makes their work easier, be testing, validating a new release for a LTS, etc. So what you are saying is that now we are on track to actually improve new releases adoption we should not make it even easier? Or go backward by cluttering stable releases with new features? Sorry, I cannot agree here. >> About 7, yes, that's our only next release. We rejected any 5.7, so we >> have to live with it. > > This has nothing to do with 5.7, 5.7 was proposed as BC break fodder, > not as release vehicle for adding enhancements. In any case, even if we > had 5.7, one it's released you can't add anything to it anymore, so > you're back to square one. In any case, you have to wait years for any > small enhancement to become available, unless you happen to be extremely > lucky to propose it just before the release of the next major. You brought the "even longer with 7" argument, 5.7 could have prevented you for having to wait "years" to get one minor features or another. That's all. >> Now, about the BC breaks, I do not see that much BC breaks for modern >> apps and even WP or D7 work quite well. Let focus on that instead of > > You know PHP world is much bigger than WP or D7, right? No comment. Pointless troll. I am the one keep saying that I do not like us using only WP to validate changes. > I've seen people > still running 5.2 in production and reluctant to go forward. Look at the > adoption figures. 5.6 is barely 1% and you propose add features into > 7.1. Who'll use them - 0.0001%? People care about WP if they run WP - > but most of them run their own apps. Or an assembly of apps, all different. Chicken-egg problem, wait until people actually moves away from old Debian/RHEL and adopt recent ones. This is what I am saying since long and in the previous paragraph. Please at least try to see that. >> starting to using 5.6 as a solution of our frustration not being able >> to move to 7, that would be terrible to have new features every patch >> release. Let do not do that. > > It would be excellent to add new features each release. Let's do that. > > You see, I can argue like you - blanket statement without any > substantiation. Can you also substantiate your position? I just did and > you rejected it with a blanket statement "no, it's terrible". No, it's > not, and the facts - including very low adoption of current versions - > support it. Until we get better adoption, I don't see how it makes any > sense to effectively ban any enhancements for 99.99% of PHP users. A blanket statement? We discussed that many times already, my stance did not change a single yota since then. I repeated it here once again to make it clear, and for the record. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Sorry for the double reply, but I wanted to pick up on one particular point. On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev wrote: >Hi! > >> That's not quite how it works; the distro package maintainers >maintain a >> sort of forked version of upstream code, combining a well-tested >> upstream release with a set of patches, many of which will be >backported >> fixes from newer releases. So the current package in Ubuntu 14.04 LTS >> [see http://packages.ubuntu.com/trusty/php5] is >"5.5.9+dfsg-1ubuntu4.7", >> and the Ubuntu Changelog shows 12 releases, mostly for security >patches, >> which is nearly as many as there have been upstream releases. > >I think this is all wrong, because I don't see how they can do better >testing with random set of patches than with real release version, but >that's beside the point. It may actually be the loose upstream definition of stability that motivates packagers to do this - they don't want to include new features, with their own potential bugs. It seems to be common practice, at least in the Debian ecosystem, so evidently they think it works out for the best. Note that they also continue to maintain their patches *after* the corresponding release branch is EOL on php.net. For instance, here is the ongoing changelog for Ubuntu 12.04LTS's package, based on PHP 5.3: http://changelogs.ubuntu.com/changelogs/pool/main/p/php5/php5_5.3.10-1ubuntu3.17/changelog If somebody were to go out of their way to install a non-default package, it's unlikely to be to include a minor change of the type we're discussing here. More likely, they would move to a newer stable branch, since the risk is only slightly higher (thanks to our minor releases being more truly minor since 5.4), and the reward much greater. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev wrote: >> This is a straw man as far as the points I made are concerned. I'm >> talking about the risk of switching from 5.5 to 5.6, which is pretty >low. > >Switching to 5.6 would be useless since what is being propose it to ban >any enhancements up to 7.1. Proposed by whom? The only mentions of 7.1 I've spotted have been from you, which is why I called it a straw man. So, rather than arguing round in circles, here's what I would propose: - Up until the first release candidate of x.y.0, small features can be added to both the most recent live branch and the new branch being prepared for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and 7.1-pre). - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug fixes only. Thus 5.5.x should not be receiving features. - As an exception to the above, when releasing x.0.0, the previous branch may continue receiving small features, until it reaches the end of its "active support" phase. In other words, keep backporting things to 5.6.x after 7.0.0 is released, since adoption of the latter is likely to be slow. By the time 7.1.0 comes around, active support for 5.6 will have ended anyway, unless we make some other exception to the normal process. This is very much a compromise between the SemVer ideal of a patch release, and the practical implications of a yearly release cycle. The aim is to make it obvious to users what they'll get in return for upgrading, and to smoothly transition a branch from "cutting edge" to "stable with bug fixes", then to "security only" and "end of life". What do people think? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > That's not quite how it works; the distro package maintainers maintain a > sort of forked version of upstream code, combining a well-tested > upstream release with a set of patches, many of which will be backported > fixes from newer releases. So the current package in Ubuntu 14.04 LTS > [see http://packages.ubuntu.com/trusty/php5] is "5.5.9+dfsg-1ubuntu4.7", > and the Ubuntu Changelog shows 12 releases, mostly for security patches, > which is nearly as many as there have been upstream releases. I think this is all wrong, because I don't see how they can do better testing with random set of patches than with real release version, but that's beside the point. The point is it's very easy to make a deployable package from php.net source pack, but it's much harder to move an organization to different version that may cause BC breaks and other disruption. It's both technical and organizational - try to propose moving software from version 5.5.23 to 5.5.24 and from 5.x to 7.x and ask anybody which is riskier. Almost universally you'd be told the latter is much riskier. > This is a straw man as far as the points I made are concerned. I'm > talking about the risk of switching from 5.5 to 5.6, which is pretty low. Switching to 5.6 would be useless since what is being propose it to ban any enhancements up to 7.1. > Well, you could fork the JSON extension, I guess. But yes, not all > options are available in all cases. For most enhancements, no options but "wait for a couple of years" are available unless you want to maintain a full-blown php fork. > That's completely the opposite of what I said. I said I *do* think > adding small features to 5.6 may be justified, since 7.0 will be a more > painful upgrade. Then we agree. But the proposal here was to ban all enhancements in released versions. This is just wrong, and I am glad you support it. > The type of backporting I'm questioning is adding features to 5.5.x, > when we have 5.6.x released, and 7.0.x in preparation. And, *after* the > 7.1.0 release towards the end of next year, I would not expect features > to be backported to 7.0. Depends on "features". In principle I'd be fine with enhancement going only into 5.6, but given its abysmal adoption so far, practically I can see the case for some stuff in 5.5 too. But I recognize it's chicken and egg problem, so if we can reach consensus on 5.6, I can live with that. > No, indeed. There, the cost is only on the developer having to ensure > that they don't deploy code relying on the new option to a server one > patch version too old. This is a regular "version requirement" concern which ops should be well familiar with and be able to handle. > prefixes like error_*, file_*, etc. So, for simplicity, you might as > well treat the global namespace as out of bounds. In my code, I'd be wary of putting non-prefixed functions into global namespace. PHP versions is only one reason - if two libraries have error_report() function, they never can be used together, not a good thing. I'd rather call it my_library_error_report() if for some reason I can't namespace it properly. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > The problem is always a definition question, a very subjective question. Fortunately, we can discuss it, we're not limited to blindly following predefined set of rules. > I do not really buy the "I am stuck with x.y" as one has the same > problem already. And he has barely a 2 years window to add them. No, right now you can add small enhancements to 5.5/5.6 and get it in production in terms of months, not several years. > About 7, yes, that's our only next release. We rejected any 5.7, so we > have to live with it. This has nothing to do with 5.7, 5.7 was proposed as BC break fodder, not as release vehicle for adding enhancements. In any case, even if we had 5.7, one it's released you can't add anything to it anymore, so you're back to square one. In any case, you have to wait years for any small enhancement to become available, unless you happen to be extremely lucky to propose it just before the release of the next major. > Now, about the BC breaks, I do not see that much BC breaks for modern > apps and even WP or D7 work quite well. Let focus on that instead of You know PHP world is much bigger than WP or D7, right? I've seen people still running 5.2 in production and reluctant to go forward. Look at the adoption figures. 5.6 is barely 1% and you propose add features into 7.1. Who'll use them - 0.0001%? People care about WP if they run WP - but most of them run their own apps. Or an assembly of apps, all different. > starting to using 5.6 as a solution of our frustration not being able > to move to 7, that would be terrible to have new features every patch > release. Let do not do that. It would be excellent to add new features each release. Let's do that. You see, I can argue like you - blanket statement without any substantiation. Can you also substantiate your position? I just did and you rejected it with a blanket statement "no, it's terrible". No, it's not, and the facts - including very low adoption of current versions - support it. Until we get better adoption, I don't see how it makes any sense to effectively ban any enhancements for 99.99% of PHP users. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Stanislav Malyshev wrote on 30/03/2015 23:10: Hi! If an organisation has standardised on an old version of PHP, there's a By "old" you're meaning current stable, I presume. No, current stable is 5.6.x; people have been talking about backporting to 5.5.x (which has 2 months of "active support" remaining according to http://php.net/supported-versions.php). fair chance that the builds they are using are not from php.net, but from their OS distribution. As has been mentioned here before, these There are no builds on php.net, except for windows.php.net. Most organizations I've encountered indeed use either distros or their own distro-like packages (which usually mimick distro ones but have modifications like additional packages, tweaking paths, adding/removing configs or data, etc.). Yes, "builds" is perhaps not the right word, but you got my meaning OK. generally track a particular patch release and cherry-pick fixes - Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official 5.5.23, for instance. Anyone working in such an environment won't receive the benefit of a new feature however far it is backported. As per above, it's much easier to get 5.5.23 installed in the org than 7.1. I'm not overly familiar with particulates of Debian policies, but if they have whole distro sitting on 5.5.9 when there's 5.5.23 out it's bad, as their customers do not get bugfixes which may be essential for them. I sincerely hope it's not the case. In any case, burden of creating 5.5.23 package from debian 5.5.9 package is very low, most competent ops would be able to do this, and That's not quite how it works; the distro package maintainers maintain a sort of forked version of upstream code, combining a well-tested upstream release with a set of patches, many of which will be backported fixes from newer releases. So the current package in Ubuntu 14.04 LTS [see http://packages.ubuntu.com/trusty/php5] is "5.5.9+dfsg-1ubuntu4.7", and the Ubuntu Changelog shows 12 releases, mostly for security patches, which is nearly as many as there have been upstream releases. the risk of following 5.5 line is not comparable to the risk of switching from 5.5 to 7.1. This is a straw man as far as the points I made are concerned. I'm talking about the risk of switching from 5.5 to 5.6, which is pretty low. The obvious alternative avenues are to write a forward-compatible userland version, or package an extension, both of which are likely to reach a larger audience than a tail-end release like 5.5.23. I'm not sure how you mean to write an extension that would add an option to json_encode for example. Well, you could fork the JSON extension, I guess. But yes, not all options are available in all cases. I can certainly see value in a special case for including things in both 5.6 and 7.x, both before and after 7.0 is released, but the the case for backporting anything other than a genuine bug fix to 5.5.x right now seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 is released (by which point 5.6.x will presumably be in its security-only phase). That means right now any enhancement somebody would propose would be just released somewhere towards the end of next year. And since nobody switches instantly, especially to the next major, their timeframe to use it would be something like 4-5 years. I would have zero motivation as a userland developer to work on a small change like adding an option that I could benefit from in 5 years maybe. Would you? That's completely the opposite of what I said. I said I *do* think adding small features to 5.6 may be justified, since 7.0 will be a more painful upgrade. The type of backporting I'm questioning is adding features to 5.5.x, when we have 5.6.x released, and 7.0.x in preparation. And, *after* the 7.1.0 release towards the end of next year, I would not expect features to be backported to 7.0. The problem is that there is no way to know, as a user, which function names may become reserved in the future. There is an officially reserved That's true in general. But if you name your function something like get_error_handler or mysql_connect_something, you must know you're on a shaky ground. The argument "we can not add anything in the main namespace because somebody could have named function exactly the same" sounds hollow to me. Of course, for some cases it must be true, but most people that don't use classes long learned to prefix or namespace their functions, and And, of course, this does not apply to adding options, etc. No, indeed. There, the cost is only on the developer having to ensure that they don't deploy code relying on the new option to a server one patch version too old. reserved. I don't think it's at all "insane" to say that a patch version shouldn't usurp non-reserved names. I think in this form it is. There are no "reserved names" in functions, and if you use mysql_* namespace functions and it clash
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 8:50 PM, Stanislav Malyshev wrote: > Hi! > >> I tend to agree that it would be easier for all parties if we stop >> adding stuff in micro versions, as it is easier to remember and > > I don't think it is a good idea. Imagine you are a PHP developer working > on a project, and you noticed there's some small functionality missing > that would improve things a lot for you - like parameter to some > function or returning some value that is missing. You could easily > contribute it, but if it can't go in minor version there's no point for > you to even bother. Because even if your org is super-up-to-date, they > run 5.6, most realistically - 5.5, and if it's like the majority - it'd > be 5.4 and worse. You could hope to convince your bosses and your ops to > go to 5.6 and keep it reasonably updated within 5.6, but if the only > addition you can make is 7.1, it's the lost cause - by the time your org > could go to 7.1 your project will be long done (or at least long > designed to work without this new feature) and you may be already > working in another company. Yes, we have releases (almost) each year, > but adoption of them is much slower, and with all BC breaks in 7.0 it > would probably be even slower when going from 5 to 7, so this means > doing small improvements to PHP is essentially of no practical value for > PHP developer since there's no chance this improvement can be used in > the lifetime of a typical project. > I do not think it would be good for PHP. > >> As everything can be considered as beeing a BC break for at least >> someone on Earth, I admit it is hard to understand the meaning of "small >> self-contained additions in a micro version" :-p > > I do not think we should consider adding functions/options "BC break", > not by any sane definition of it. Of course, nothing prevents somebody > from using insane definitions, but it's of no concern to us. The problem is always a definition question, a very subjective question. I do not really buy the "I am stuck with x.y" as one has the same problem already. And he has barely a 2 years window to add them. About 7, yes, that's our only next release. We rejected any 5.7, so we have to live with it. Now, about the BC breaks, I do not see that much BC breaks for modern apps and even WP or D7 work quite well. Let focus on that instead of starting to using 5.6 as a solution of our frustration not being able to move to 7, that would be terrible to have new features every patch release. Let do not do that. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > If an organisation has standardised on an old version of PHP, there's a By "old" you're meaning current stable, I presume. > fair chance that the builds they are using are not from php.net, but > from their OS distribution. As has been mentioned here before, these There are no builds on php.net, except for windows.php.net. Most organizations I've encountered indeed use either distros or their own distro-like packages (which usually mimick distro ones but have modifications like additional packages, tweaking paths, adding/removing configs or data, etc.). > generally track a particular patch release and cherry-pick fixes - > Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official > 5.5.23, for instance. Anyone working in such an environment won't > receive the benefit of a new feature however far it is backported. As per above, it's much easier to get 5.5.23 installed in the org than 7.1. I'm not overly familiar with particulates of Debian policies, but if they have whole distro sitting on 5.5.9 when there's 5.5.23 out it's bad, as their customers do not get bugfixes which may be essential for them. I sincerely hope it's not the case. In any case, burden of creating 5.5.23 package from debian 5.5.9 package is very low, most competent ops would be able to do this, and the risk of following 5.5 line is not comparable to the risk of switching from 5.5 to 7.1. > The obvious alternative avenues are to write a forward-compatible > userland version, or package an extension, both of which are likely to > reach a larger audience than a tail-end release like 5.5.23. I'm not sure how you mean to write an extension that would add an option to json_encode for example. > I can certainly see value in a special case for including things in both > 5.6 and 7.x, both before and after 7.0 is released, but the the case for > backporting anything other than a genuine bug fix to 5.5.x right now > seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 > is released (by which point 5.6.x will presumably be in its > security-only phase). That means right now any enhancement somebody would propose would be just released somewhere towards the end of next year. And since nobody switches instantly, especially to the next major, their timeframe to use it would be something like 4-5 years. I would have zero motivation as a userland developer to work on a small change like adding an option that I could benefit from in 5 years maybe. Would you? > The problem is that there is no way to know, as a user, which function > names may become reserved in the future. There is an officially reserved That's true in general. But if you name your function something like get_error_handler or mysql_connect_something, you must know you're on a shaky ground. The argument "we can not add anything in the main namespace because somebody could have named function exactly the same" sounds hollow to me. Of course, for some cases it must be true, but most people that don't use classes long learned to prefix or namespace their functions, and And, of course, this does not apply to adding options, etc. > reserved. I don't think it's at all "insane" to say that a patch version > shouldn't usurp non-reserved names. I think in this form it is. There are no "reserved names" in functions, and if you use mysql_* namespace functions and it clashes with functions added by mysql extension, it's your fault. Same for other obvious cases. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 30/03/2015 19:50, Stanislav Malyshev wrote: Hi! I tend to agree that it would be easier for all parties if we stop adding stuff in micro versions, as it is easier to remember and I don't think it is a good idea. Imagine you are a PHP developer working on a project, and you noticed there's some small functionality missing that would improve things a lot for you - like parameter to some function or returning some value that is missing. You could easily contribute it, but if it can't go in minor version there's no point for you to even bother. Because even if your org is super-up-to-date, they run 5.6, most realistically - 5.5, and if it's like the majority - it'd be 5.4 and worse. You could hope to convince your bosses and your ops to go to 5.6 and keep it reasonably updated within 5.6, but if the only addition you can make is 7.1, it's the lost cause - by the time your org could go to 7.1 your project will be long done (or at least long designed to work without this new feature) and you may be already working in another company. If an organisation has standardised on an old version of PHP, there's a fair chance that the builds they are using are not from php.net, but from their OS distribution. As has been mentioned here before, these generally track a particular patch release and cherry-pick fixes - Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official 5.5.23, for instance. Anyone working in such an environment won't receive the benefit of a new feature however far it is backported. The obvious alternative avenues are to write a forward-compatible userland version, or package an extension, both of which are likely to reach a larger audience than a tail-end release like 5.5.23. I can certainly see value in a special case for including things in both 5.6 and 7.x, both before and after 7.0 is released, but the the case for backporting anything other than a genuine bug fix to 5.5.x right now seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 is released (by which point 5.6.x will presumably be in its security-only phase). As everything can be considered as beeing a BC break for at least someone on Earth, I admit it is hard to understand the meaning of "small self-contained additions in a micro version" :-p I do not think we should consider adding functions/options "BC break", not by any sane definition of it. Of course, nothing prevents somebody from using insane definitions, but it's of no concern to us. The problem is that there is no way to know, as a user, which function names may become reserved in the future. There is an officially reserved namespace "php\", but it remains unused. So if functions can be added at any time, the only way to guarantee your code won't break on a patch upgrade is to treat the entire global namespace as additionally reserved. I don't think it's at all "insane" to say that a patch version shouldn't usurp non-reserved names. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! > I tend to agree that it would be easier for all parties if we stop > adding stuff in micro versions, as it is easier to remember and I don't think it is a good idea. Imagine you are a PHP developer working on a project, and you noticed there's some small functionality missing that would improve things a lot for you - like parameter to some function or returning some value that is missing. You could easily contribute it, but if it can't go in minor version there's no point for you to even bother. Because even if your org is super-up-to-date, they run 5.6, most realistically - 5.5, and if it's like the majority - it'd be 5.4 and worse. You could hope to convince your bosses and your ops to go to 5.6 and keep it reasonably updated within 5.6, but if the only addition you can make is 7.1, it's the lost cause - by the time your org could go to 7.1 your project will be long done (or at least long designed to work without this new feature) and you may be already working in another company. Yes, we have releases (almost) each year, but adoption of them is much slower, and with all BC breaks in 7.0 it would probably be even slower when going from 5 to 7, so this means doing small improvements to PHP is essentially of no practical value for PHP developer since there's no chance this improvement can be used in the lifetime of a typical project. I do not think it would be good for PHP. > As everything can be considered as beeing a BC break for at least > someone on Earth, I admit it is hard to understand the meaning of "small > self-contained additions in a micro version" :-p I do not think we should consider adding functions/options "BC break", not by any sane definition of it. Of course, nothing prevents somebody from using insane definitions, but it's of no concern to us. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 4:04 AM, Ferenc Kovacs wrote: > Hi, > > I know that our official release process allows that, but there are some > reasonable arguments against doing that and this topic was brought up > multiple times related to specific fixes. > I have two open PRs like that: > https://github.com/php/php-src/pull/1204 > https://github.com/php/php-src/pull/969 > and of course there are a bunch of similar ones from other people, and > there are cases when somebody simply pushes a change like that, other times > somebody points out that it should require an RFC( > https://wiki.php.net/rfc/json_preserve_fractional_part for example), but > most of the times we simply don't know what to do, and eventually we just > let the PR/patch to rot and die. > I would like to know if we can come up with a rule which can have consensus > behind it, and maybe formalize it as an extension to our current > releaseprocess rfc. I personally do not want to see *any* features go into a patch release (the Z in X.Y.Z). It's not just a pain to document, but there's no real reason to do this because we have minor releases (the Y in X.Y.Z) each year. I'd even like to tighten up on what "bug fixes" we allow into patch releases, as I think we have been far too accepting in the past. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 3:10 PM, Ferenc Kovacs wrote:
>
>
> On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner wrote:
>
>> On 30/03/15 12:04, Ferenc Kovacs wrote:
>> > Hi,
>> >
>> > I know that our official release process allows that, but there are some
>> > reasonable arguments against doing that and this topic was brought up
>> > multiple times related to specific fixes.
>> > I have two open PRs like that:
>> > https://github.com/php/php-src/pull/1204
>> > https://github.com/php/php-src/pull/969
>> > and of course there are a bunch of similar ones from other people, and
>> > there are cases when somebody simply pushes a change like that, other
>> times
>> > somebody points out that it should require an RFC(
>> > https://wiki.php.net/rfc/json_preserve_fractional_part for example),
>> but
>> > most of the times we simply don't know what to do, and eventually we
>> just
>> > let the PR/patch to rot and die.
>> > I would like to know if we can come up with a rule which can have
>> consensus
>> > behind it, and maybe formalize it as an extension to our current
>> > releaseprocess rfc.
>> >
>> > What do you think?
>> >
>>
>> How about:
>>
>> It's okay, if it does not need `version_compare(PHP_VERSION)` but can be
>> tested by e.g. `defined("SOME_CONSTANT")` or `function_exists("fn")`?
>>
>> --
>> Regards,
>> Mike
>>
>
> hi,
>
> That is a good think to keep in mind, but I don't think that is the only
> thing matters.
> Adding a new function/constants -> there is a chance that we break
> somebodys code in a micro version
> Adding a new class method -> can be problematic if somebody extended the
> class and used the same method but with different signature.
> As of now, we don't really consider this kind of things as BC breaks
> (otherwise nothing but new optional arguments would be allowed in micro and
> minor versions), but it is a PITA for those whose app we break in a micro
> version.
> I tend to agree that it would be easier for all parties if we stop adding
> stuff in micro versions, as it is easier to remember and communicate that
> something was added in x.y (as in x.y.0) than the current situation where
> some stuff is just only present in 5.6.27, plus this would also eliminate
> the confusion, that something is present in 5.6.27 but not in
> 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will
> land in 5.5.41).
>
I agree.
That was the case for 5.6 for example, that got added new functions etc...
up to 5.6.3 AFAIR.
As everything can be considered as beeing a BC break for at least someone
on Earth, I admit it is hard to understand the meaning of "small
self-contained additions in a micro version" :-p
Julien.Pauli
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner wrote:
> On 30/03/15 12:04, Ferenc Kovacs wrote:
> > Hi,
> >
> > I know that our official release process allows that, but there are some
> > reasonable arguments against doing that and this topic was brought up
> > multiple times related to specific fixes.
> > I have two open PRs like that:
> > https://github.com/php/php-src/pull/1204
> > https://github.com/php/php-src/pull/969
> > and of course there are a bunch of similar ones from other people, and
> > there are cases when somebody simply pushes a change like that, other
> times
> > somebody points out that it should require an RFC(
> > https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
> > most of the times we simply don't know what to do, and eventually we just
> > let the PR/patch to rot and die.
> > I would like to know if we can come up with a rule which can have
> consensus
> > behind it, and maybe formalize it as an extension to our current
> > releaseprocess rfc.
> >
> > What do you think?
> >
>
> How about:
>
> It's okay, if it does not need `version_compare(PHP_VERSION)` but can be
> tested by e.g. `defined("SOME_CONSTANT")` or `function_exists("fn")`?
>
> --
> Regards,
> Mike
>
hi,
That is a good think to keep in mind, but I don't think that is the only
thing matters.
Adding a new function/constants -> there is a chance that we break
somebodys code in a micro version
Adding a new class method -> can be problematic if somebody extended the
class and used the same method but with different signature.
As of now, we don't really consider this kind of things as BC breaks
(otherwise nothing but new optional arguments would be allowed in micro and
minor versions), but it is a PITA for those whose app we break in a micro
version.
I tend to agree that it would be easier for all parties if we stop adding
stuff in micro versions, as it is easier to remember and communicate that
something was added in x.y (as in x.y.0) than the current situation where
some stuff is just only present in 5.6.27, plus this would also eliminate
the confusion, that something is present in 5.6.27 but not in
5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will
land in 5.5.41).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mar 30, 2015 6:15 PM, "Michael Wallner" wrote:
>
> On 30/03/15 12:04, Ferenc Kovacs wrote:
> > Hi,
> >
> > I know that our official release process allows that, but there are some
> > reasonable arguments against doing that and this topic was brought up
> > multiple times related to specific fixes.
> > I have two open PRs like that:
> > https://github.com/php/php-src/pull/1204
> > https://github.com/php/php-src/pull/969
> > and of course there are a bunch of similar ones from other people, and
> > there are cases when somebody simply pushes a change like that, other
times
> > somebody points out that it should require an RFC(
> > https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
> > most of the times we simply don't know what to do, and eventually we
just
> > let the PR/patch to rot and die.
> > I would like to know if we can come up with a rule which can have
consensus
> > behind it, and maybe formalize it as an extension to our current
> > releaseprocess rfc.
> >
> > What do you think?
> >
>
> How about:
>
> It's okay, if it does not need `version_compare(PHP_VERSION)` but can be
> tested by e.g. `defined("SOME_CONSTANT")` or `function_exists("fn")`?
We have php version constants, major, minor and patch.
To me it all looks the same, ugly #ifdef like. Now that we release a x.y+1
every year, I do not see the point to continue to force our users to
clutter their codes with such tests.
> --
> Regards,
> Mike
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 30/03/15 12:04, Ferenc Kovacs wrote:
> Hi,
>
> I know that our official release process allows that, but there are some
> reasonable arguments against doing that and this topic was brought up
> multiple times related to specific fixes.
> I have two open PRs like that:
> https://github.com/php/php-src/pull/1204
> https://github.com/php/php-src/pull/969
> and of course there are a bunch of similar ones from other people, and
> there are cases when somebody simply pushes a change like that, other times
> somebody points out that it should require an RFC(
> https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
> most of the times we simply don't know what to do, and eventually we just
> let the PR/patch to rot and die.
> I would like to know if we can come up with a rule which can have consensus
> behind it, and maybe formalize it as an extension to our current
> releaseprocess rfc.
>
> What do you think?
>
How about:
It's okay, if it does not need `version_compare(PHP_VERSION)` but can be
tested by e.g. `defined("SOME_CONSTANT")` or `function_exists("fn")`?
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
