Latest update on the "New Project" issue:
I think I've found the offending code for real this time. There is code
for a version check that checks that the Flex version is less than 5.0.0
by doing:
major * 100 + minor * 10 + micro
This means that we don't have the option to change to Apache Flex 5.0.0 to
get around this problem, and further means that someday when we really
mean to do 5.0 we'll have this problem again.
There is a class called MXMLVersion2009.java that creates an instance of
org.osgi.Framework.Version like this:
init(..., ...,
new Version(4,5,0), new Version(5,0,0), new Version(4,0,0));
It looks like the expectation was that these versions would get updated
when FB had synchronized releases with Adobe Flex SDKs. We need to go in
an change that 5 to something larger somehow.
I am passing the same information on to the FB team at Adobe.
-Alex
On 7/29/13 7:46 AM, "Scott Guthmann" <sc...@on3solutions.com> wrote:
>>I am hoping we're going to release something other than RC3 which means
>>we have a few more days before we would release. Here's my latest
>>update on the 3 issues:
>>
>>1) ResourceModule via FlashVars: Yes it affects a small population of
>>the total Flex SWFs in the world, but at least two of folks who took the
>>time to try the RC found it. I have a fix ready to go.
>>2) This FB Issue. I am trying to get a response from the FB team. And
>>I'm looking through their source to try to find the actual cause. If we
>>cut another RC, we should at minimum update the release notes in the
>>>kits themselves to describe this issue and its workaround. But maybe
>>>by the time we get the next RC ready we'll have more information.
>>3) The Ilist issue. The bug author's workaround was to stop using
>>DataList. Not everyone has the luxury of doing that, so IMO, we really
>>don't have a workaround. And this will affect LCDS customers. I think
>>we >should revert the change to Ilist, but we don't have to revert the
>>change to ListCollectionView.
>>
>>So, I would prefer we cut another RC at least to address #1 and #3, and
>>maybe we'll come up with a better plan for #2 during that time.
>>
>>-Alex
>
>To release or not to release - that is the question....
>+1 to Alex's approach. Strategically, it is better to release something
>that provides developers with a good user experience. Releasing something
>that requires deletion of files to work right or a patch to several of
>the IDEs that are standard is a bad idea. Some of the goals we should
>have when we test to determine if the RC should move forward: 1) Does the
>SDK RC work smoothly on mac, windows, and Linux? 2) Does the AIR
>installer work smoothly on mac, windows, and linux? 3) do the binary
>distributions work smoothly on each of these platforms? 4) Are the manual
>builds of the SDK and the binary versions supported by the top IDEs:
>IntelliJ, Flash Builder, Flash Develop, and FDT?
>
>My opinion is that we are not adequately evaluating if the RC versions
>are meeting these developer user experience questions when voting on an
>them. The community millions of devs are not as capable of the patching &
>work arounds as you guys are. The best marketing you can do is creating a
>feature rich product that is easy to use for any skill level - make it
>simple (which is difficult to do).
