On 12/18/12 10:32 AM, "Om" <bigosma...@gmail.com> wrote:
> On Tue, Dec 18, 2012 at 10:06 AM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>>
>> On 12/18/12 9:50 AM, "Om" <bigosma...@gmail.com> wrote:
>>
>>> In theory, yes. But the RCs are changing so fast that it is hard to keep
>>> track of. Since the next RC is going to be cut from the release branch, I
>>> think testing the release branch should be fine.
>>
>
>
>> Actually, I think I am going to claim that the only "correct" procedure is
>> to test the actual RC. That ensures that nothing went wrong in the
>> packaging. Otherwise, how can you really vote on the RC? I guess you can
>> bin-diff the files in the RC vs the release branch and show that there are
>> no differences, but that seems like an extra and slow step.
>>
>>
> I disagree. This excercise has NOTHING to with any Release Candidate. The
> 'correct' approach is to first test on all different combinations, ensure
> that everything works as we want to claim and then cut a release. I would
> go as far as stopping any new RCs before we get all these test scenarios
> completed.
OK, I guess I missed a decision somewhere. I thought this exercise was to
approve the RC. If Justin withdraws the RC vote, then I will know you are
right. But frankly, I think we should just test the RC and vote on it and
get it out the door.
>
> Once an RC is cut, individuals are free to test on whatever platform/flash
> player version/AIR version they want and indicate that in their +1 or -1
> vote for the RC.
And because the RC does not have its own copy of the mustella tests, you
have to use the recipe I described below if you plan to test the RC with
mustella.
>
>
>
>> Also, right now I think that there might be some changes to mustella in the
>> develop branch that haven't been sync'd over to release 4.9. Step 0 in the
>> future should be to run mustella on the develop branch before cutting the
>> release branch.
>>
>>
> Then let us all switch to testing the develop branch first on various
> combinations before cutting the release branch.
If Justin agrees to this plan, I will try to sync up the release branch's
mustella tests. It will take a while as I will need to make sure that
mustella change aren't tied to develop branch checkins. And I'll have to run
the mini_run -all on the release branch overnight.
>
>
>
>> My recipe (on Win, will try to run Mac tonight):
>>
>> -Download the RC.
>> -Unzip to a folder (c:\apacheflex4.9)
>> -Change the build.properties if you are trying different player version
>> -Setup the required environment variables
>> -Make sure FLASHPLAYER_DEBUGGER environment variable is pointing to right
>> player if you are using a different player version
>> -run ant main checkintests
>> -Set FLEX_HOME environment variable to the folder
>> (FLEX_HOME=c:/apacheflex4.9). Note the forward slash for Cygwin.
>> -Change to develop branch's mustella folder
>> -Uncomment and edit local.properties to point sdk.dir to c:/apacheflex4.9
>> -run ./mini_run.sh -all
>> -run ./mini_run.sh -failures -rerun
>>
>>
>
> You are mixing source trees here (downloaded apache 4.9 vs. develop branch)
> I am not sure what the intent is.
The RC does not contain the full mustella suite (not very useful to most
folks) so you need to be able to redirect a branch's mustella run against an
external set of SWCs and compiler.
>
> Also, the RC is baked with a version of flash player.
The FlashPlayer is not in the RC. But I assume you are talking about the
swf-version in the library.swfs in the SWCs and the default value set in
build.properties and flex-config.xml. We have to decide as a community
which version to use to build the binary kit. I assume it is the one
checked in in those files. Whatever version we decide on, we gamble that
anyone using the binary kit will not find incompatibilities with the
bytecode in the SWCs and whatever flash player version they actually use to
build their app. So far, I know of no incompatibility. The swf-version in
the SWCs is never used to dictate anything in an running SWF. Only the
swf-version of the first SWF loaded dictates the API for all subsequent SWFs
that get loaded. But you are right that the bin kit theoretically requires
a whole new matrix of testing. I just don't think it is required if we test
the RC or source branch against different player versions. The compiler
should catch use of unavailable APIs and I think the bytecode output has not
changed.
> If you are going to
> use the RC to test various combinations, then you are missing the
> 'compile' step after we change the flash player version.
I don't think so, I am running ant main checkintests after changing the
player version, so that should run the compile step. Or maybe I'm not
understanding you.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
