Even though the 5.2 code base is fairly mature, it is far from being bug
free. Unit tests are often a good way to identify corner cases that may
not be handled properly even in the stable branches, so more tests IMHO
is a good thing. Until the decision is made to discontinue the 5.2
branch, which should be done eventually, maybe even later this year, we
should not neglect it from any standpoint, especially tests.

On 10-03-11 5:06 PM, Christopher Jones wrote:
>
>
> Eric Stewart wrote:
>
> > Focusing TestFest on 5.3 was not how I had envisioned TestFest 2010,
> I was
> > operating under the assumption we would be committing all applicable
> tests
> > to 5.2, 5.3 and 6.0 as was done last year. Focusing strictly on 5.3
> > certainly makes my job (and others working on TestFest 2010) easier
> but I
> > wasn't aware that anyone was even entertaining this.
> >
> > This is obviously not strictly on point with this discussion and I
> don't
> > think a divergence from the main topic is appropriate at this
> moment. But it
> > underscores the importance that we will be much better off hashing
> this out
> > sooner rather than later as things in the near future will certainly
> bear
> > significant effects.
> >
> > As this thread winds down and consensus is reached, I'll bring this
> > particular topic up again on the QA List with a discussion based on
> results
> > of late events.
> >
> > Eric Lee Stewart
> >
>
> I think they should be merged to 5.3 and trunk (which is the "branch"
> I really meant in my previous email, not 5.4).
>
> Looking at e.g. the DBA tests, I am building with 3 different versions
> of the Berkeley DB client library.  With OCI8 tests I build with three
> different client libraries and then test against three different DB
> versions.  Repeating this kind of effort for 5.2 at this mature stage
> of its life isn't worthwhile use of resources IMHO (when no code has
> changed).  In a perfect world we'd do it, but where we are now I think
> we need to focus the efforts of testers on 5.3+.
>
> Chris
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to