Re: Proposal of removing PHP4 references from the manual

On 16 July 2014 08:04, Maciej Sobaczewski <msobaczewski@gmail.com> wrote: > Ok, so maybe to start with something little less controversial and easy to > do. I reviewed en/reference/* and made list of books which refers only to > PHP 4.x (with few exceptions as you will see). > > Extensions/modules built in PHP and not available in PHP 5: > - book.dotnet > - book.hw (replaced by book.hwapi) > - book.swf > - book.xslt > - book.qtdom > - book.i18n > - book.w32api > - book.notes > - book.objaggregation > - book.java > - book.msession: "(PHP 4 >= 4.2.0, PHP 5 <= 5.1.2)", so everything depends > on version we consider as a base > - book.fam: "(PHP 5 <= 5.0.5)", so everything depends on version we > consider as a base > - book.soap: "(PHP 5 <= 5.0.1)" (or 5.0.5, or 5.1.2), so everything > depends on version we consider as a base > And as noted above, the soap extension is still alive and kicking. And fam appears to have a release and be installable. > PECL extensions not available for PHP 5: > - ext/printer: no releases available on > http://pecl.php.net/package/ > printer > - ext/ovrimos: no releases available on ?T–[ªbŽ[˜c!í > http://pecl.php.net/package/ > ovrimos > - ext/vpopmail: last (and the only one) release on 2004-03-11 so few > months before PHP 5.0.0 release > - ext/openal: last (and the only one) release on 2003-09-22 so almost one > year before PHP 5.0.0 release > - ext/oggvorbis: last (and the only one) release on 2003-09-10 so almost > one year before PHP 5.0.0 release > - ext/kadm5: last (and the only one) release on 2003-06-03 so over one > year before PHP 5.0.0 release > - ext/dbplus: last (and the only one) release on 2003-06-24 so over one > year before PHP 5.0.0 release > - ext/cyrus: last (and the only one) release on 2003-05-21 so over one > year before PHP 5.0.0 release; package marked as unmaintained on > pecl.php.net > - ext/spplus: last (and the only one) release on 2002-11-09 so almost two > years before PHP 5.0.0 release; package marked as unmaintained on > pecl.php.net > - ext/classkit: last release on 2004-09-06; package marked as supressed > and replaced by ext/runkit on pecl.php.net > - ext/iisfunc: quote from "Installation" section: "This extension is > considered unmaintained and dead. However, the source code for this > extension is still available within PECL SVN here: » > http://svn.php.net/viewvc/pecl/iisfunc" > - ext/session_pgsql: quote from "Installation" section: "This extension is > considered unmaintained and dead. However, the source code for this > extension is still available within PECL SVN here: » > http://svn.php.net/viewvc/pecl/session_pgsql" > I would push what to do with PECL extensions to another discussion, this should only about what to do about PHP 4 references in the docs. It would be nice to have a purge, or clear out, of stale PECL exts that are not usable... but one step at a time. For exts that have no releases, they shouldn't be in the docs. But for "old" releases, the question is whether they're still installable on current PHP versions. Just because something is unmaintained, doesn't mean it's not useful and usable. > > I would be *very* glad if someone could find time to verify this list > again. Then I can delete those books. > > Note for the outraged people: this process was began long time ago, but it > was done only partially. It is an attempt to make it complete. > > Thanks, > Maciej. > Finally, are we coming to a decision on a course of action? - /manual/php4.php mega page of nostalgia - remove PHP 4-only chapters - finish removing *all* inline PHP 4 references - versions.xml and changelogs... *to be decided (or, win by committing first)* - PECL exts: can we move this to another discussion as it's not really about PHP 4 I'd like to suggest that we just start moving on with actually making changes, for a few reasons: - Discussions are boring; getting stuff done is fun - Everything is under version control, if someone gets overzealous then we can add stuff back - We're all grown ups and can make decisions about what to do, and/or ask for help/guidance/clarification - It's about damn time PHP 4 was sent on its merry way!