Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates
 64.18.1.23 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: Maurice Amsellem <maurice.amsellem@systar.com>,
        "dev@flex.apache.org"
	<dev@flex.apache.org>
Date: Thu, 10 Oct 2013 09:11:43 -0700
Subject: Re: Build failed in Jenkins: flex-sdk_mustella #460 (fixed)
Thread-Topic: Build failed in Jenkins: flex-sdk_mustella #460 (fixed)
Thread-Index: Ac7F02xyUIGo8DWbSLamug0LzMKfjw==
Message-ID: <CE7C1E84.1E67F%aharui@adobe.com>
In-Reply-To: 
 <2095F5EBE04D59409DFCE91FFCEBF7AF3F532C12@EXMBX05.netplexity.local>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 10/10/13 8:58 AM, "Maurice Amsellem" <maurice.amsellem@systar.com>
wrote:

>I get it. =20
>
>So I will try to change the code so that it supports both the old
>behavior (ie by subclassing) and new behavior (ie by styling).
I'm sure some users will be very happy if you do that.  You don't have to,
you just have to judge how many people will be impacted and whether it
will cause them to think poorly of Apache Flex.  For example, for the
FTETextField issue, we may decide that the FTETextField has always been
behaving incorrectly and change the tests and tell folks they'll have to
change any code affected by it because they were relying on buggy
behavior.  We will use performance considerations in that decision because
there are often hundreds of FTETextFields on screen at once, whereas
SplitViewNavigator probably only has a few.

Thanks,
Alex