Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates
 64.18.1.77 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Tue, 18 Dec 2012 14:24:07 -0800
Subject: Re: Apache Flex 4.9 Release Candidate 3
Thread-Topic: Apache Flex 4.9 Release Candidate 3
Thread-Index: Ac3dauRpLWnML9RdQFaXUX7EMwlYFwAA4BXt
Message-ID: <CCF62D07.4A308%aharui@adobe.com>
In-Reply-To: <A070CBF6-B1B8-4F01-AB6E-B9AED38E2D88@classsoftware.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.13.0.120411
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 12/18/12 1:58 PM, "Justin Mclean" <justin@classsoftware.com> wrote:

> Hi,
>=20
>>  Which is useful, but somewhat disturbing information as it
>> potentially increases the number of possible rendering environments.
>=20
> I don't think we can possible test every combination here that's:
> OS version (at least 2) x compile for FP (x8) x run in FP versions (x8) x
> supported locales (x22) x AIR (x5) =3D 14000+ combinations :-)
The "run in" is more than 8.  Nick showed that you have to test swf-version
N in every one of the 8 players that supports swf-version N.
>=20
>> I have code locally that will store the display list as XML alongside ea=
ch
>> baseline, but I haven't check it in.  I thought it would be too disrupti=
ve
>> and was going to wait until after we get the release out.
> I assume you can run the test in XML only mode? Perhaps that would be goo=
d
> enough for testing a different locale if the en_US locale passes?
A different locale would change the display list XML because the text
property of a TextField would be in that locale.  The XML is only set up as
a backup.  If the bitmap compare fails, we check the XML to see if it
matches then we know (hope) the failures are rendering issues in the player=
,
not our code.
>=20
>> In fact, after we get the release out, I think I want to move mustella t=
o
>> its own top-level folder.
> That may make it hard to keep in sync when creating/testing a release
> candidate.
I'll start a new thread if/when I get more serious about it.  We'd probably
add tests that we know won't run (for example, Carol's about to check in
some Spark DG locked row/column features and tests into develop that isn't
in release) to an excludes file.  I'm just tired of waiting for mustella
tests to download when checking out a branch, and the XML files will make i=
t
worse.
>=20
> Thanks,
> Justin

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui