Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65658 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95215 invoked from network); 5 Feb 2013 06:36:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2013 06:36:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=karoly@negyesi.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=karoly@negyesi.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain negyesi.net from 209.85.216.170 cause and error) X-PHP-List-Original-Sender: karoly@negyesi.net X-Host-Fingerprint: 209.85.216.170 mail-qc0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:51428] helo=mail-qc0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 25/10-28596-768A0115 for ; Tue, 05 Feb 2013 01:36:23 -0500 Received: by mail-qc0-f170.google.com with SMTP id d42so2989200qca.15 for ; Mon, 04 Feb 2013 22:36:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=K51UpgC3b7og9cONmzfHJ48WkTYgfFMsfuWKlXT6ywE=; b=Oq/PzKTgbqGka8/WUUPQw+LtLlyJWVcHvRcxpjQArS62ZJWIL6qPo6T2NzqvWB6e/r LPpLosZJWvVPeeTfhQj1INWipW/TIyKQzyGGTG1sDi8iiBgk67Rpg0pYpjwFrFdQS5Yz U2KxaFCSGTaFuZpoWopqQtJI9PL+pepWME8AXzN1BWTd65rTRd9kxOE8+bCTEMUDdzGk +xfVEimkqvtyg+lP51Imrz4T5bcJZd5oE1nXzQ1SpD4g2p2TO8r5Vvw2bbu30kdmGjop wTgN20AMJXJO85NxgXtk0gHbaUdB/gHSPH+QUO0LpEPpSm+G91eFesxamXuhqEgledHS skmA== X-Received: by 10.229.176.134 with SMTP id be6mr4655766qcb.65.1360046179967; Mon, 04 Feb 2013 22:36:19 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by mx.google.com with ESMTPS id f7sm11156617qap.13.2013.02.04.22.36.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 22:36:18 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id j34so2944186qco.37 for ; Mon, 04 Feb 2013 22:36:17 -0800 (PST) X-Received: by 10.229.193.134 with SMTP id du6mr4646258qcb.46.1360046177655; Mon, 04 Feb 2013 22:36:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.97.65 with HTTP; Mon, 4 Feb 2013 22:35:57 -0800 (PST) In-Reply-To: References: <510EBF98.4060900@lerdorf.com> Date: Mon, 4 Feb 2013 22:35:57 -0800 Message-ID: To: Kris Craig Cc: Rasmus Lerdorf , "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnyv3GBmP26yKpY+hg+Njq74bS89ex8MXWD/VceoXiNxKD9Cz3aZeyjiSy5dY/TTh2RRfIY Subject: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning From: karoly@negyesi.net (Karoly Negyesi) OK, let's try this again. Maybe language versioning is out. That's sad, but this thread brought to light a much more important problem I would like to try to address. I have long felt the PHP team is living in another world I do. Let me describe my world. I am working on an open source package. So does another 1000 or so developers. And another 10 000 adds modules (or maybe you'd call them plugins). I do not even know how many then adds custom, site specific code. This whole pile of software forms an ecosystem which is quite sizeable. The software is somewhat popular. Users form a pyramid. The bottom is shared hosts. Shared hosts that we need to take into consideration. So if the shared world just barely switched to 5.3 default then, alas, we can't release a version that requires PHP 5.4 because there is no shared support for it. Also, it worths mentioning that one of the more popular server OSes, Ubuntu LTS also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts won't upgrade. This is a vicious circle that is superb hard to break. I was told in this thread that the new release process solves this and "it is our and our users role to explain that to their ISPs, admins, etc". Well, what am I to explain? As I mentioned previously, if a shared host does a PHP upgrade and their users see new error messages, then the host have a support problem. When I tried to point this out, I got strawman arguments (about segfaults and bugfixes which breaking forward compatibility and absolutely having nothing to do with BC) and ridicule ("the problem is with your code"). You can ridicule the codebase all you want, but the codebase a) works b) tested. This doesn't change the fact that breaking backwards compatibility a little is like being a little pregnant. Either you are or you are not and currently you are not. This is sad because apparently a lot of work is being put into this and then on a minor point it falls short of the goal. It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. I would absolutely love not to have this conversation again three years from now when we need to decide to ship Drupal 9 with PHP 5.5 or 5.4 -- because we could indeed do a campaign when 5.4 is due to change to 5.5 outright because it won't break BC with 5.4. Is this absolutely unattainable? Best regards Karoly Negyesi