Re: 2.0.0 (Re: [PEAR-DEV] PEAR 1.9.5 testing)
| From: | Alexey Borzov | Date: | Tue, 15 Jul 2014 16:53:16 +0000 |
| Subject: | Re: 2.0.0 (Re: [PEAR-DEV] PEAR 1.9.5 testing) | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-55386@lists.php.net to get a copy of this message | ||
Hi Christian,
On 15.07.2014 20:45, Christian Weiske wrote:
Exactly.We don't want to rewrite it.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.
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?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 VersionsDropping support for PHP4 is a BC break - which is why many PHP5 rewrites of the packages got a 2 in their package name.
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