Re: [PEAR-DEV] 2.0.0 (Re: [PEAR-DEV] PEAR 1.9.5 testing)

[email protected] (Alexey Borzov) Tue, 15 Jul 2014 20:46:24 +0400
Newsgroups php.pear.dev
Message-ID <[email protected]>
Hi Vasil,

::sigh::

If we release PEAR 1.10 requiring PHP5, then
  * PHP4 users will not suffer a BC break since they will be unable to upgrade 
to 1.10
  * PHP5 users will not suffer a BC break since their code will continue to run 
happily

Maybe we'll need to provide an 1.9 based go-pear.phar, though.

Of course, we'll be unable to release a completely E_STRICT and exception-using 
version, but that will require the previously mentioned complete rewrite anyway.


On 15.07.2014 20:40, Vasil Rangelov wrote:
>> We don't need a BC break to drop PHP4 support, this was discussed quite a
> bit, I think.
>
> Dropping PHP4 support is ITSELF a BC break, is it not? A BC break after all
> is when old code won't work with a new setup, i.e. PHP4 (the old)
> code doesn't work with the next PEAR (the new "setup"), since to run PEAR
> requires higher PHP version.
>
> That said, it's obviously a long time coming to drop PHP4 in one way or
> another, be it with PEAR or Pyrus...
>
> And I agree that it's better if it's Pyrus, perhaps with a Pyrus plugin for
> pickle, for the sake of PECL extensions.
>
>
> 2014-07-15 19:28 GMT+03:00 Alexey Borzov <[email protected]>:
>
>> Hi Till,
>>
>>
>> On 15.07.2014 20:11, till wrote:
>>
>>> was wondering what you thought about going 2.0.0-alpha1 and dropping
>>>>>> PHP4 support once and for all.
>>>>>>
>>>>>
>>>>> Where does that leave Pyrus?
>>>>>
>>>>
>>>> I don't see a future for Pyrus.
>>>>
>>>> Nobody is working on it, and it is not on-par with the features PEAR
>>>> currently has - as well as a plethora of open bugs I opened years ago.
>>>>
>>>> See https://github.com/pyrus/Pyrus/issues
>>>>
>>>
>>>
>>> I agree with Christian.
>>>
>>> My thoughts were not to throw it all away and write the installer from
>>> scratch.
>>>
>>
>> "Not keeping BC / going 2.0.0 / whatever" is only needed if we rewrite
>> from scratch.
>>
>>
>>   An alpha1 could have bugfixes and so on from the roadmap and maybe one or
>>> two dependencies swapped out/updated. E.g. I'd rather use HTTP_Request2 in
>>> there than to rewrite another HTTP layer, etc.. I'd swap out pecl-related
>>> code for pickle[1] etc. pp.. Why — because it's code that's maintained.
>>>
>>
>> Yes, I'm going to change PEAR to use HTTP_Request2. This does not require
>> version 2.0.0 and will not break BC.
>>
>>
>>   Just granularly tackle current issues and modernize the code base. Not a
>>> complete rewrite. (cc Alexey)
>>>
>>
>> What prevents doing it with version 1.10?
>>
>>
>>   A 2.0 would allow us BC breaks, e.g. to drop PHP4 support, which might
>>> even
>>> make it fun to work on it.
>>>
>>
>> We don't need a BC break to drop PHP4 support, this was discussed quite a
>> bit, I think.
>>
>> I'd suggest going with Pyrus if we want a brand new version, its problems
>> are not code-related but [lack-of-]doc-related and people-related mostly.
>>
>>
>> --
>> PEAR Development Mailing List (http://pear.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>