Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106517 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42490 invoked from network); 10 Aug 2019 01:34:05 -0000 Received: from unknown (HELO mail-qt1-f170.google.com) (209.85.160.170) by pb1.pair.com with SMTP; 10 Aug 2019 01:34:05 -0000 Received: by mail-qt1-f170.google.com with SMTP id 44so66352865qtg.11 for ; Fri, 09 Aug 2019 16:01:35 -0700 (PDT) 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=H1z21y7kUMPqnf+lCsU1791vpBkbYlLgIGhANFRHDKM=; b=sQ0COWFVJhWudf6w/nK5+nZ98phbGRAFFbNN7dYur0TqByVRVThvqeiCXzTPbVEOVr qpEyG8Tih4TP8MkM7QCmAdBVmn4hdHiBWENIIYEiS+ceZe4ynFlfm9sr1YT0Hcq2lfsG nvhp4meIFvHsfmjg/PKliZyAhM8dMf96KvsRyzlRUHS/7dnRVv2ClYZWU+9qvuhCgZNg LXKKf59B5eRqJxVbaaSVZaeR4QzHRKRQbyz+p0viPZwfxkWWrb1rQSuUz4HbCIEqJ2hq QPq+8vDnu6IcNlmrvQLN8rcU6/i4zZSPopPNrFNJaq46LABtW+vzpnky7GSh71iby5ch nLhg== X-Gm-Message-State: APjAAAUk6i2Ap+EGZk3ZBNhrx3sYYRo1HJkjbqXgO6bXcV45CC4QIW8i w+/qzxhBrN3iOPjwXxN8WlrljEggkuY2gKlDSDregw== X-Google-Smtp-Source: APXvYqzfAhBBdlm6+QzX33iZ46i70zac88L2lrnQaMKxhMrfvlhPMFWUPuQuaiX06vLza7dkCO3Zd1WdvbTx4vQwikM= X-Received: by 2002:aed:2667:: with SMTP id z94mr11418352qtc.343.1565391695572; Fri, 09 Aug 2019 16:01:35 -0700 (PDT) MIME-Version: 1.0 References: <5d4dd72b.1c69fb81.5f91e.f6eaSMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: Date: Fri, 9 Aug 2019 18:01:24 -0500 Message-ID: To: Zeev Suraski Cc: Mark Randall , Internals Content-Type: multipart/alternative; boundary="000000000000f2fab1058fb72703" Subject: Re: [PHP-DEV] Re: P++: FAQ From: pollita@php.net (Sara Golemon) --000000000000f2fab1058fb72703 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 9, 2019 at 4:30 PM Zeev Suraski wrote: > In the spirit of my response to Bob, I added a new FAQ: "How does this > differ from Nikita's Editions idea?" > > """Related to rollout - the Editions approach doesn't allow for just two dialects - but any number of dialects. We could have a PHP2020 dialect, along with a PHP2022 dialect and a PHP2027 dialect. If we keep them all - this may actually increase our maintenance complexity.""" I don't think we would keep them all. We could set a sunset cycle for dialects similar to branch support cycles. PHP2020 comes out and we support that along with PHP1996. Two years later, we introduce PHP2022 and we continue to support 2020 and 1996. When PHP2024 comes out, we drop PHP1996. When PHP 2026 comes out, we drop PHP2020, etc.... This does introduce a point where legacy apps must fix their code or simply not upgrade, but it also provides a path to upgrade to latest support version, then migrate files one at a time to that version's latest, allowing an update to latest-latest. This is significantly better than the current state of syntax BC breaks which requires all updates to occur WITH the upgrade. Meanwhile, we have a little more work (work you and Niki are both suggesting we take on already), but with a bounded cap on how long we carry complications around. -Sara --000000000000f2fab1058fb72703--