Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119873
MIME-Version: 1.0
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com> <CADK1yXLie-hPJwKSUqpBgpOkWPBrBvcaXdFfLKxDMPbcT=1dYA@mail.gmail.com>
In-Reply-To: <CADK1yXLie-hPJwKSUqpBgpOkWPBrBvcaXdFfLKxDMPbcT=1dYA@mail.gmail.com>
Date: Mon, 10 Apr 2023 21:01:17 +0200
Message-ID: <CAJmy8YHeSEHsNdu3pmzFaB9c2c8v=8W-kU-4iJKUo0UOBwJG0Q@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Stephan Soller <stephan.soller@helionweb.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Future stability of PHP?
From: divinity76@gmail.com (Hans Henrik Bergan)

several PHP versions will be maintained for 10 years by third-party vendors=
.
PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com
maintains PHP5.6 with multiple customers paying 6000=E2=82=AC/year for 5.6
maintenance.
Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu
Pro 16.04.
Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu
Pro 18.04.
Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu
Pro 20.04.
Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu
Pro 22.04.

Red Hat does something similar for their RHEL customers. ~~

On Mon, 10 Apr 2023 at 20:30, Deleu <deleugyn@gmail.com> wrote:
>
> On Mon, Apr 10, 2023, 1:17 PM Pierre Joye <pierre.php@gmail.com> wrote:
>
> > hello,
> >
> >
> > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <stephan.soller@helionweb.d=
e>
> > wrote:
> >
> > > Hello,
> > >
> > > I'm sorry if this isn't the correct mailing list for that discussion =
but
> > I
> > > couldn't find a more appropriate one where people actually know how t=
he
> > > wind is
> > > blowing.
> > >
> > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amoun=
t of
> > > deprecations and fatal errors spooked me a bit (details below if you'=
re
> > > interested). That got me wondering about the long-term stability of P=
HP
> > > (as in
> > > language and API breaks) and I looked at the RFCs. I got the impressi=
on
> > > that
> > > static typing has a lot of traction now and I have no idea of what th=
e
> > > fallout
> > > might be of changing a dynamically typed language into a statically
> > > typed one.
> >
> >
> > I keep reading this in multiple languages, pr even more frameworks.
> >
> > I understand agency work, managers pushing new features instead of a
> > cleaning some legacy.
> >
> > however years of ignoring deprecation notices (very few were introduced
> > right before 8.0).
> >
> > Most of them could have been fixed within a couple of hours in any code
> > base, if they had tests.
> >
> > I would suggest, very very nicely, to review and rethink the developmen=
t
> > flows of these projects instead of asking php to freeze.
> >
> > best,
> > Pierre
> >
>
> I resent the sentiment of "if your code or development process was exactl=
y
> like mine you wouldn't be here complaining" and I believe nobody is askin=
g
> PHP to freeze. Not everyone has the ability to fix every deprecation with=
in
> a couple of hours and not everyone has tests. Yes, we get it, it's common
> knowledge nowadays that code without test is unmanageable, but if you
> inherited a 15 year old codebase developed by multiple developers in a
> start-up mentality producing code faster than they could actually plan fo=
r
> and with no tests, its going to take some time to clean that up and if I
> take longer than you would, does it mean I matter less as a PHP user?
>
> PHP 8 is pretty great to work with and a lot better than previous version=
s,
> but there was no opt-in aspect to a lot of PHP breakages. All that we're
> asking here is for a bit more forgiveness to existing code that was
> developed 2 decades ago by a complete different generation and still need
> to run today while we clean it up.
>
> >