Hello,
a) There is no windows version PHP4.4
His 4.4 typo is ameliorated by the comment about 4.2 later, no? :-)
How about by your typos in the reply :-) :-) :-)
Yeah, yeah, yeah. A version number is a bigger deal for typos. Still, it's pretty obvious which package he meant, given the context.
b) Version 4.2.0 is not out (its a release candidate)
So it's really 4.2.0RC1 that *is* out, if you want to get real pedantic. :-)
c) If you don't know how to handle the libraries for testing with this
RC1, then testing is not a good job for you.
The actualyrelease will have all libraries bundled.
d) If RC1 doesn't have the libraries bundled to be tested properly, it's a bad RC... :-)
Seriously -- If it's not what's going to be released, it's not an RC. Might be a Beta, but not an RC, as I understand the term:
Release Candidate -- What the average end-user should expect to see, to work out of the box, exactly as-is. Except maybe a version number and maybe a disclaimer about the suitability of production use.
Is that not what "RC" means?
If we expect wide-spread testing of an "RC", we should have a true bundle of what they can expect in 4.2.0 (final) that can be tested, not some bundle of things with parts missing that isn't what we expect to be in 4.2.0 final.
Jim's user-experience seems perfectly valid to me, the naive user -- This "Release Candidate" is not in a suitable state for release under Windows.
Is there a very important technical reason why it can't be done, or why testers must somehow magically know how to dig out and install the other DLLs from their non-working location within the bundle or some external resource?
Have we documented this important distinction between what one should expect in a "Release Candidate" and the reality of what's there?
I'm not trying to be an ass nor negative -- I truly have no idea why that stuff isn't in our Windows download where it would be for a "real" release, why we shouldn't expect it to be there, nor where I'd go to try and get the missing pieces if I had a Windows box to test on...
I'm not the Release Master, but if I *were*, with what limited knowledge I have available to me now, I'd say we needed an RC2 with the correct DLLs in it exactly where they will be for "final"
Apologies if this DLL dichotomy of RC1 and release was hashed out somewhere and I missed it...
Derick
On Thu, 21 Mar 2002, jren wrote:
Hi there:
New version windows PHP4.4 provide new xsl module call php_xslt.dll,
it is from the pack of downloading.
But that pack does not include the sablot.dll,xmlparse.dll and xmltok.dll.
I have Version4.05 php_salot.dll,sablot.dll,xmlparse.dll and xmltok.dll. it is working fine.
but When I use php_xslt.dll replace php_salot.dll,I got error "can not load php_xslt.dll".
I know that may be Version4.2 have new sablot.dll,xmlparse.dll and xmltok.dll.
but I donot know where can I get it.
thanks
Jim
-----------------------------------------------------------------------
PHP: Scripting the Web - derick@php.net
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
-----------------------------------------------------------------------
--
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
--
Got Music? http://l-i-e.com/artists.htm