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

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

On 15.07.2014 20:45, Christian Weiske wrote:
>>> was wondering what you thought about going 2.0.0-alpha1 and
>>> dropping PHP4 support once and for all.
>> We already have PEAR2, it is called Pyrus and it is stuck in alpha
>> for 5 years.
>>
>> Starting another complete rewrite with the amount of workforce we
>> have is madness.
>
> We don't want to rewrite it.

Exactly.

>> Yep. This does not require going 2.0.0, though.
>
> If I understand the BC rules[2] correctly, we may only break BC when the
> major version is incremented:
>
>> Deliberatly Breaking BC on packages
>> Breaking BC may only be done:
>> [...] moving from Major Package Versions
>
> Dropping support for PHP4 is a BC break - which is why many PHP5
> rewrites of the packages got a 2 in their package name.

These packages also have a radically different API.

We won't change API, we will only up the PHP version requirement. E.g. upping 
required version from 4.3 to 4.4 is not a BC break? Even if users of PHP 4.3 
won't be able to upgrade to a newer version of the package?

Why upping the requirement from PHP 4.4 to PHP 5.2 is a BC break, then?

> Theoretically we are forced to rename the package to PEAR2, but I'm
> totally against that - PHP4 is EOL'd since ages, and only a handful
> servers world wide are running it.
>
> This is why I propose to increase the version number to 2, but keep the
> package name (and thus the class name).
>
> I'd use the 2.x.y as indicator that PHP4 support has been dropped.

That is against our own rules. And again, we already have (stillborn) PEAR2.

> [1] http://pear.php.net/group/docs/20031114-bbr.php
> [2] http://pear.php.net/manual/en/rfc.version-naming.standard.php
>