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/unsub.php
