Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85617 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14634 invoked from network); 31 Mar 2015 23:47:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Mar 2015 23:47:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 74.125.82.53 mail-wg0-f53.google.com Received: from [74.125.82.53] ([74.125.82.53:34552] helo=mail-wg0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 46/15-19757-6223B155 for ; Tue, 31 Mar 2015 18:47:51 -0500 Received: by wgbdm7 with SMTP id dm7so35968912wgb.1 for ; Tue, 31 Mar 2015 16:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xvhXovUhg1B1seXg2RIiJiM9fagQ/dXEnrHN6rmy1E8=; b=ylqP4Al8d0BLIDfAxJlM8oojkhzvllw9xZFXQnC1qCvFXvvmNYaQIJw8tCgB9N+otO 3sBHnIHvc/WJt9P+yPySYiP0QxaM9NpdBgJ3z67qRw30wJdVFx48/Y/PPiOm8OGQXQvy w71ryTk4czHVwj1NwtE01iW61oGaolHmyVh6c0iAVl+m4bhuiTraqhHKqYGL1NBBcWlv IYkMVhRQCD9kpuq3iBMUuMOw2BrnfA+Ks72neewPequzVO6Kd7ul7yq1eClPXzqvrEiP SsJ6Q1Dgo2smohhtsLvsbAtCEGtTofb00QyR/jIWFp8tUtJ1d2FCXiwycn2v75Ba+nII fEJQ== MIME-Version: 1.0 X-Received: by 10.194.79.226 with SMTP id m2mr77340720wjx.60.1427845667427; Tue, 31 Mar 2015 16:47:47 -0700 (PDT) Received: by 10.194.236.6 with HTTP; Tue, 31 Mar 2015 16:47:47 -0700 (PDT) In-Reply-To: <551AFC1E.6010501@gmail.com> References: <55193060.5000804@php.net> <55199AE8.4090100@gmail.com> <551AFC1E.6010501@gmail.com> Date: Wed, 1 Apr 2015 06:47:47 +0700 Message-ID: To: Stanislav Malyshev Cc: Julien Pauli , Ferenc Kovacs , Michael Wallner , PHP Internals , Stanislav Malyshev Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version From: pierre.php@gmail.com (Pierre Joye) 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