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 >