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 <smalys...@gmail.com> 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
