Uwe Schindler wrote:
I would update NSAPI as I always did, there were just no new bugs and code is very stable 
(to the extend of "stableness" of multithreaded SAPIs). It is still also in use 
on some of my servers, so I would still help support it.
UWE, If its used on some of your servers, and you are supporting it then it doesn't belong on my suggested list. :-)
At the moment I did not follow recent commits to SAPI-related code, so I have 
to closer look into it. Are there any RFCs related to changes coming in 5.6 for 
OPcache?
Not currently.
-----Original Message-----
From: Terry Ellison [mailto:ellison.te...@gmail.com]
Sent: Monday, August 19, 2013 6:05 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Which OSs and SAPI should PHP 5.6 support?

By way of a background.  I've been doing a review of the exting code base
looking at how to establishing a roadmap extend OPcache functionality
across all supported OSes and SAPIs.  And this raises a supplementary Q:
which OSs and SAPIs should we be supporting for PHP 5.6 anyway?  I would
be interested in the  views of the dev team on this.

It would be good to agree a list of which OSs are to be supported at PHP 5.6,
which SAPIs are supported, and a matrix of which SAPIs are supported on
non-threaded and build TSRM variants.

Examples of what I am talking about are SAPIs with no clear evidence of
active support (I've listed the last non-bulk change in brackets to give a
measure of the level of support):
      aolserver (2008), caudium (2005), continuity (2004), nsapi (2011),
      phttpd (2002), pi3web (2003), roxon (2002), thttpd (2002),
      tux (2007), webjames (2006)
I realise that some of these may still be actively used with a user community
out there wanting to track current versions, and this is just a case of "if 
ain't
broke..."  However, I do wonder when some of these were actively
maintained and routinely tested against the current versions at release -- and
if not then perhaps PHP 5.6 is the correct point to retire them from the
source tarball and configure options? ...

Reply via email to