Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107495 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 54582 invoked from network); 11 Oct 2019 12:47:53 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 11 Oct 2019 12:47:53 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 2385C2D200A for ; Fri, 11 Oct 2019 03:31:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,RDNS_NONE, SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.0.0.0/16 X-Spam-Virus: No Received: from mint.phcomp.co.uk (unknown [IPv6:2001:4d48:ad51:2f00::2:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Fri, 11 Oct 2019 03:31:00 -0700 (PDT) Received: from addw by mint.phcomp.co.uk with local (Exim 4.92.3) (envelope-from ) id 1iIsCH-0003SB-MH for internals@lists.php.net; Fri, 11 Oct 2019 11:30:57 +0100 Date: Fri, 11 Oct 2019 11:30:57 +0100 To: internals@lists.php.net Message-ID: <20191011103057.GX16775@phcomp.co.uk> Mail-Followup-To: internals@lists.php.net References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Organization: Parliament Hill Computers Ltd User-Agent: Mutt/1.5.20 (2009-12-10) X-Envelope-From: Subject: Re: [PHP-DEV] Migration tooling and the cumulative cost of purely syntactical deprecations From: addw@phcomp.co.uk (Alain D D Williams) On Fri, Oct 11, 2019 at 12:25:11PM +0200, Nikita Popov wrote: > Rather than starting a holy war over every single RFC that contains the > word "deprecation", I think we should take a look at our migration story > and possibly invest some effort into creating a "blessed" tool for this > purpose: One that only performs migrations that are completely safe and > should be runnable without fear of breaking code. > > I do realize that there is already quite a bit of existing tooling, things > like Rector, various CS fixers and compatibility scanners, but I don't > think that we have anything that just works out of the box to do what is > safe and no more. Could I suggest an option for it to point out where other (unsafe) migrations could/should be done so that we know where to look. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include