Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128817
Precedence: list
MIME-Version: 1.0
References: <CAOD_yv0k=1nBq6LOR9w2pNXHnjtPL5NtBV=SLRsKjpVCK1dFug@mail.gmail.com>
 <fdf1d284-27bf-4bb2-924e-21fa82673c6f@gmx.de> <CAOD_yv2Sga6P1N-Uu2w-nyyY-XMvytWy-_r1v=xZpygQ_67iRQ@mail.gmail.com>
 <CAEZPtU6NJfxjckrpikVfmFcJ2OyhhKg3YJdqTkpvPaU_uMeyGg@mail.gmail.com>
 <CAEKnhAEsGS+k7Mg4Z1z-fbWh4hsAbkpgTxsdJEYaG7N1+F=Ddg@mail.gmail.com>
 <CAEZPtU4PLw7-Tu4vUVqHus71maeTsQuAKQxVbqLxSkY9eErDyg@mail.gmail.com> <CAEKnhAFTkrXPdPw3rXbLUPY-shHwTYxTSqM3cLBY7iRCaqrfHA@mail.gmail.com>
In-Reply-To: <CAEKnhAFTkrXPdPw3rXbLUPY-shHwTYxTSqM3cLBY7iRCaqrfHA@mail.gmail.com>
Date: Sun, 12 Oct 2025 10:30:40 +0700
Message-ID: <CAEZPtU47NHVNty=VKbnAANqhqWzHrh=ztFnGCGQzfAs6QSAf6g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate PEAR and recommend Composer
To: Jakub Zelenka <bukka@php.net>
Cc: james@asgrim.com, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	PHP Internals List <internals@lists.php.net>, ashnazg@php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: pierre.php@gmail.com (Pierre Joye)

On Sun, Oct 12, 2025 at 2:13=E2=80=AFAM Jakub Zelenka <bukka@php.net> wrote=
:

> Ok so I guess the current status is kind on unknown... :) But as noted by=
 Rowan in other email, there's a mention of the PEAR Group that is the gove=
rning body of the project although seems expired so I have really no idea w=
hat the governance there is and if the RFC process should have any power ov=
er that project.
>
>> > I don't think that any current core developer has access to their GH o=
rganizattion. Or do you still have access / control to do any changes there=
 and make it deprecated? My main issue with this RFC is that it's about pro=
ject that we don't effectively control and I'm not sure here is anyone who =
can make any such change to it. From what I see it's currently maintained b=
y Chuck who, I guess, also control the project. Or am I wrong?
>>
>> I do have access, I did not check the role tho'.
>>
>
> I guess this is really the crucial part here. Are you able / willing / co=
mfortable to potentially update the website or the tool if we approve the R=
FC about deprecation and are you sure that the current maintainer is ok wit=
h that (basically respect RFC as the governance method for PEAR)?

To make it simple, PEAR is part of the PHP projects. There was a
separate group to do the admin work, security releases when needed,
sync with php releases to bundle it, etc.

For the purpose of fading out pear, and, more importantly, pecl, we
can handle it here using the normal RFC flow. Most of the group
members are barely (f.e. me) or not active at all anymore.

>> 1. mail the pear-dev ML and maintainers about the plan
>>
>> 2. disable any new releases, some are still released
>> (f.e.https://pear.php.net/package/Log/)
>> 3. add (future) service shutdown to the pear home page and/or in the
>> site header
>> 4. archive releases somewhere (static's php.net maybe?)
>> 5. Once shutdown's date is reached, static page with link to the
>> archive for the releases (for the few people still using them)
>>
>
> Ok but this assumes that we are able to do 2 and 3.

And 1. :)


>> The removal for php's dists is obviously a good first step but I would
>> not do it in minor releases tho'. I have seen internal projects here
>> and there still running (php8 too :), and using pear, let's give them
>> a last bit of time to see the light maybe?
>
>
> If we are talking just about removing everything in php-src, then I don't=
 think it's issue to get rid of it in 8.6 but we should for sure have RFC t=
o decide it.

I agree, easy to greap the phar when needed but communication is key
to avoid bad surprises. Maybe a pre warning in the upcoming 8.5
release.

Best,
--=20
Pierre

@pierrejoye | http://www.libgd.org