Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103447 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10270 invoked from network); 16 Nov 2018 19:05:49 -0000 Received: from unknown (HELO mail-io1-f47.google.com) (209.85.166.47) by pb1.pair.com with SMTP; 16 Nov 2018 19:05:49 -0000 Received: by mail-io1-f47.google.com with SMTP id f6so14324302iob.1 for ; Fri, 16 Nov 2018 07:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NZjBxDj8L/490hqFmn7kLX8wjuk/j/uGsVUL60tk0Ww=; b=PuaiAWtVm22IOyptOfQl1ZuUgC1yrt8X267px02aE9dAonufITNlrRkNQCaZX3NfFP cv7JVE7FCDmCDW/rVk/l3KI6J9J1jOwqbBWBuDgLwhFYUafhZNyK4GOqo8T7TVyQ11KA jNwylas0b5lE1SI550XvxHaXslSHDiCByywIkHOBn7YG+CodTvIZ5kelvAHG6Vj5OCPe yMcOKR9M3KcIw8c+O3Sfe+zOMbX8oSMeTANsAe39E9JbOqUeMzj8Mxqr3g/eZuLiFi9N 2bKcw9LgUy85b6XVq2dsBNMPjIX8IGUOIQYE1DDXMgzLwN8bw57NJFwxwwe829Uy0i38 //yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NZjBxDj8L/490hqFmn7kLX8wjuk/j/uGsVUL60tk0Ww=; b=XLIMH6kauHUYAGa70RG8BD2y5i8Ip6HRpMG0vEo+82dnTgiOjrZ9ov9YCal8FAQXqe qNega0po4U4wKWPJ/Y+orA3pjxQ4eqdsBvYyRx5pYcUUuon5vDgw0jeiZsTVIywDRst9 rDlbMenDZgT251iDT34HfbxfYB0LJPQYCRoEbo8zjeJg3A/TmB6Ck3EsC161IYWOoU1I kCGa5QboyGP4Axh5Vc49x6CVn2B/G/RHAu4FBcI1J0iMhAt6qnhrbR4eJSgi0HgqNnX+ HDxaGezpQ+0DaoKa1DM1B1ciYwL1/d+SbjnToB20HGNgX8c8hVf7Mq2kplXqX2/A4ddO y++g== X-Gm-Message-State: AGRZ1gLx439uAT2jHNATbMsovaBJOF2wbp/4wclEJQ0bO78S2sPx5jbv 0PLAhBnL9Q28l2H6Z1kU32ec9STmunEZoPbUBNw= X-Google-Smtp-Source: AJdET5dOjIHwCfo8tNz2qCAntOZq1dmtXk51iSVbPmR0kqrWrqnx+jTZT6I1ZXNgREG1YnqsJUSIN5kVz3jX80RokNM= X-Received: by 2002:a6b:5814:: with SMTP id m20-v6mr7535957iob.47.1542382002983; Fri, 16 Nov 2018 07:26:42 -0800 (PST) MIME-Version: 1.0 References: <091debad-319d-7010-4852-fb9d7e6304ac@gmx.de> <52d491a2-f546-f1eb-09e4-87f1b070d256@zend.com> In-Reply-To: Date: Fri, 16 Nov 2018 16:26:25 +0100 Message-ID: To: Sara Golemon Cc: Dmitry Stogov , zeev@php.net, Christoph Becker , PHP internals Content-Type: multipart/alternative; boundary="00000000000065561d057ac9cbe9" Subject: Re: [PHP-DEV] Re: Branch off PHP-7.4 early From: nikita.ppv@gmail.com (Nikita Popov) --00000000000065561d057ac9cbe9 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 16, 2018 at 4:10 PM Sara Golemon wrote: > On Fri, Nov 16, 2018 at 7:17 AM Dmitry Stogov wrote: > > - in the near future (by mid January) fork PHP-8 and start active > > development there. Keep PHP-7.4 development in master, and don't require > > committers to merge into PHP-8, but restrict PHP-7.4 for minor changes > > or features that won't significantly affect PHP-8 branch. > > > > - in May/June move master into PHP-7.4, make PHP-8 to be master and > > require committers to work on master and backport changes (according to > > usual PHP/GIT workflow). > > > If fixes are not required to be merged to PHP-8, then how do we ensure > that those fixes (especially the security ones) will still be in > effect when 8.0 is released? > Changes are still merged into 8.0. It's just not the responsibility of the individual contributor to merge every single commit as it is made. Instead the people working on the PHP 8 branch perform merges as needed. E.g. Dmitry has been maintaining a JIT branch for many years now, by semi-regularly merging current master into it. Basically just the way a standard long-term feature branch works. > To target typed-properties or other significant changes to PHP-7.4, it's > > better to commit them before PHP-8 branching. > > > How will that impact deprecations? Are we calling those "not > significant"? I'd actually say yeah since they tend to take the form > of a few lines of "stop doing this". I do worry about our ability to > pull a deprecations list together by January though. > Deprecations have to go into 7.4, there's no other option there. Creating a PHP 8 feature branch does not mean that changes (even language changes) can't be applied to PHP 7.4. It may be slightly more convenient if large changes like typed properties land before branching, but it's not a hard requirement. FTR; This feels like the worst available option. It's basically just > early branching with bad names. I'd much sooner branch PHP-7.4 in > January and have that be it. > I feel like there may be some understanding here, because what is proposed here seems to match exactly what you proposed in your first mail to this thread. Nikita --00000000000065561d057ac9cbe9--