Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63869
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.184 cause and error)
Message-ID: <50A36F44.4040402@lsces.co.uk>
Date: Wed, 14 Nov 2012 10:15:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120826 Firefox/15.0 SeaMonkey/2.12
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <CADajX4CYZdNpgQv46m_6J7tQLBc=h6HxCn-bGpxr3Ou2VaqgBg@mail.gmail.com> <50A197D2.5070307@oracle.com> <50A21576.2010307@lsces.co.uk> <50A33C72.7040308@sugarcrm.com> <50A35F96.3040603@lsces.co.uk> <50A36532.3050005@b1-systems.de>
In-Reply-To: <50A36532.3050005@b1-systems.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: lester@lsces.co.uk (Lester Caine)

Ralf Lang wrote:
> Unmaintained Software will retain unfixed bugs, unfixed security
> holes and ultimately break because of external changes. the mysql
> extension maintainers do not want to or cannot support the extension for
> much longer.

Is there anything drastic that still needs to be fixed in the current version of 
the extension? Can't we just start developing a 'legacy' build which will be 
available as an fallback and something that others can lightly maintain in terms 
of any critical security stuff? The idea of an LTS version has been continually 
shot down, but having something that can reliably run legacy code and where 
working versions of 'eol' extensions like mysql can be stored, rather than the 
vague hit and miss situation currently where we as developers have no idea what 
an ISP's setup may be using versions wise? I make no apology for repeating that 
this SHOULD have been done before PHP5.3 was pushed out and I would be 
interested to see if there IS any interest in reopening PHP5.2 as a legacy 
platform, as certainly 5.3/4 do not provide that base! At least it would provide 
a reference point to work from.

Crib sheets of information on how to move code from the legacy base to the 
current build are then easier to develop while currently if PHP5.2 code has not 
been 'updated to' 5.3, then moving it two or now three versions is even more 
painful. And we still do not have good references of how code SHOULD be built 
nowadays. Certainly my own code bases are apparently archaic but just fixing 
E_STRICT warnings does not produce clean PHP5.4 code, just bodged 5.? stuff :(

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk