> 2. Technical issues
> 2.1. Key objects.
>
> /usr/lib/libphp5-5.2.0.so
> /usr/lib/libphp5.so -> /usr/lib/libphp5-5.2.0.so
>
> All other objects will be contained within the /usr/php5/[version]
> hierarchy. This hierarchy will loosely track that of the publicly
> available version.
>
> The current version of PHP5 [5.2.0] is 64-bit clean and largefile
> aware. A 64-bit version of PHP is being considered for a future
> release.
Why shouldn't 64 bit libraries be part of the initial putback?
>
> 2.2. Versioning
>
> The PHP5 development process follows the ubiquitous
> "continuous development" model, typical of many Open Source projects.
> Currently, two Releases of PHP coexist, and are still under
> development: PHP4 and PHP5. Also, PHP6 is currently under active
> development, and is scheduled to be released sometime during 2007.
> None of these three Releases make any guarantees of API and ABI
> compatibility.
>
> The PHP versioning model has followed the <Release>.<Major>.<Minor>
> model. The version of PHP5 proposed for inclusion in Solaris is PHP
> 5.2.0.
>
> 2.3. Directory Naming and Structure
>
> The proposed directory layout for PHP5 is:
> /usr/php5/
> bin -> [version]/bin
> doc -> [version]/doc
> etc -> /etc/php5
> include -> [version]/include
> lib -> [version]/lib
> man -> [version]/man
> modules -> [version]/modules
> share -> [version]/share
I don't have a particular issue with this naming scheme for
managing change. What I'd like to have stated is if there
is a precedent that is being followed and where that
precedent was established. And, if there isn't an established
precedent, if this case is intended to set the precedent.
How/when are obsolete instances expected to be removed.
> 6.2. Imported Interfaces.
>
> NAME STABILITY NOTES
>
> Apache 2.2 APR Libraries Uncommitted PSARC/2007/000
> OpenSSL [Secure Sockets Layer] External/Volatile PSARC/2003/500
How will change be managed?
Gary..
