> Why shouldn't 64 bit libraries be part of the initial putback? Speaking for myself, although I believe delivering 64-bit versions of the support libraries makes sense (assuming the open source components are 64-bit clean), I don't believe delivering a 64-bit PHP is necessary at this time.
I've spoken to a number of customers and developers about this and while a 64-bit PHP or Apache is certainly something desirable, it has not been expressed as a strong requirement for the moment. If someone though has data to show that this is not the case, that would definitely be of interest. Also as Stefan noted in the case, there are additional enhancements that are being looked at for the future concerning PHP and I think 64-bit could be one of them. >> 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. I believe the precedent that is being followed here is that of Perl (PSARC 1999/192). > How/when are obsolete instances expected to be removed. Again, I think the model here is akin to Perl. dsc
