Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65589
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain seancoates.com from 64.15.79.181 cause and error)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <CAOfzkkz3DC+aVb4c73QHGRzZv=1z=nG4uexdJh2n8h3ATGBBOA@mail.gmail.com>
Date: Sun, 3 Feb 2013 17:16:54 -0500
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <13717571-594A-4DAD-AF75-1829C7D6F432@seancoates.com>
References: <CAOfzkkz3DC+aVb4c73QHGRzZv=1z=nG4uexdJh2n8h3ATGBBOA@mail.gmail.com>
To: Karoly Negyesi <karoly@negyesi.net>
Subject: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
From: sean@seancoates.com (Sean Coates)

> So, if we are talking about PHP 6, then the opening <?php tag should =
be
> accompanied by the version it was written for, it was tested with and =
then
> the engine could switch to a compatibility mode for that version.
>=20
> Seems to me that this would solve the problem where a host can't =
upgrade to
> a more modern version for fear of breaking old code. Consequently, =
open
> source packages -- like Drupal I am deeply involved with -- can't use =
more
> modern PHP versions decreasing the "push" for hosts to upgrade. This =
is a
> devilish circle and it'd be great to break it.

Agreed with the others that this should not go into the engine (and this =
should also not really clutter up the Internals list), but if you have a =
real need for running different versions of PHP for different URLs, you =
could pretty easily set up multiple FPM backends (one for each version =
you support) and have Nginx map URLs to these. It would be a maintenance =
headache, but not the disaster this would be if it had to be maintained =
in PHP-proper.

S