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

From: 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:
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


« previous php.pear.dev (#55386) next »