Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75806 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57833 invoked from network); 21 Jul 2014 16:10:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jul 2014 16:10:09 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.42 as permitted sender) X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.192.42 mail-qg0-f42.google.com Received: from [209.85.192.42] ([209.85.192.42:46914] helo=mail-qg0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4B/50-55793-F5B3DC35 for ; Mon, 21 Jul 2014 12:10:07 -0400 Received: by mail-qg0-f42.google.com with SMTP id j5so5691305qga.1 for ; Mon, 21 Jul 2014 09:10:03 -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=zIZWk7XBkbTURY4NXTItJeYBlnQ/IjFR6uRuNU00OYc=; b=Nj9R9g2OUXC12qXXsYv0AIMzQwB/JO0ULCcT8N/DV7jRnjihEIIhCnO5uor39WukaD C/VdqNRig1i7i3yTgqTXqyY8vpKYPQD1Xwgz/4ysI3HQXGXPlEwuNN8D2+kgGOCrVkjP nu6+EK+HvRiJU6IeE2P247ra1oGSet0QogERsgxlAEZEvQyWPLbo0n83QelWqsoADzft vSfjhf4ZRZFjqdPYX6rPn/euTIlNbDvF7LbPohy+uvFI06pav4Yv+QnyQ0sD5SnPM1KU MNHMe2b4oODaLIqVQI62XQ5uZNnisJTno0Hw/4agunozNnPWBdUSvAqsULJq/N5YebE/ fLXA== MIME-Version: 1.0 X-Received: by 10.224.4.73 with SMTP id 9mr44252793qaq.12.1405959003740; Mon, 21 Jul 2014 09:10:03 -0700 (PDT) Received: by 10.140.102.111 with HTTP; Mon, 21 Jul 2014 09:10:03 -0700 (PDT) In-Reply-To: <-6299216022086038902@unknownmsgid> References: <-6299216022086038902@unknownmsgid> Date: Mon, 21 Jul 2014 18:10:03 +0200 Message-ID: To: Xinchen Hui Cc: Zeev Suraski , Yasuo Ohgaki , PHP internals Content-Type: multipart/alternative; boundary=001a11c21edafcc3a204feb6566f Subject: Re: [PHP-DEV] RFC: Move phpng to master From: tyra3l@gmail.com (Ferenc Kovacs) --001a11c21edafcc3a204feb6566f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui wrote: > Hey: > > > =E5=9C=A8 2014=E5=B9=B47=E6=9C=8821=E6=97=A5=EF=BC=8C19:02=EF=BC=8CFere= nc Kovacs =E5=86=99=E9=81=93=EF=BC=9A > > > >> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote: > >> > >> > >> > >> He just asks if we will have a 5.7 release while working on the next > major > >> in master. > >> > >> I don't think that we can release the php-next under a years, so I thi= nk > >> that an 5.7 could be warranted (to keep up with our roadmap), but > depends > >> on wether or not we have enough new (BC-safe) features. > >> > >> I don=E2=80=99t see a reason of why we can=E2=80=99t have this major v= ersion ready by or > >> even sooner than the current yearly rhythm we have. In fact, if we do > aim > >> to work in parallel on both 5.7 and .NEXT =EF=BF=BD we=E2=80=99re like= ly to needlessly > >> delay .NEXT=E2=80=A6 > >> > >> > >> > >> Zeev > > > > because there is so much stuff which we want to do in the next major > > version, but we can't even start because there is no stable base to > target > > the other php-next features. > What they are? Please come with RFC and Patches. > https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/size_t_and_int64_next > Or you suggest we stop the current work to waiting them come their self? > I'm saying that we should resolve the current situation where people can't work on stuff which would target php-next, because it is still a moving target. I'm saying that it is nice that you(the phpng main devs) are confident that you can stabilize your changes so making a php-next release in less than a year, but other people have other ideas which can only happen in a major version, and you shouldn't rush an early release which would mean that the next window of opportunity for major refactor is in the next decade. I'm saying that it is pretty unfortunate that we have to decide to between reviewing/accepting a huuuuuuuge chunk of changes or rejecting a significant performance boost and some api cleanup. I'm saying that we should stop pushing our own agendas, and figure out the best possible solution for the current situation, so that we can go forward with the development with the normal workflow, where everybody is on the same page, controversial changes are done through RFCs and we don't block each other from the work. --=20 Ferenc Kov=C3=A1cs @Tyr43l - http://tyrael.hu --001a11c21edafcc3a204feb6566f--