You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Om <bi...@gmail.com> on 2012/12/18 01:05:35 UTC
We need your help testing Flex 4.9 with various Flash Player versions
Justin has been working hard on getting Flex 4.9 into shape for a release.
He has also made it possible to easily switch between different versions
of Flash Player while compiling the SDK.
This is where you come in. Before we release, it would be great if we can
compile and run the Mustella test suite against each version of the Flash
Player we want to support. Here are the detailed instructions on how to
switch between Flash Player versions before compiling the SDK:
How to compile Flex for different versions of Flash Player:
https://cwiki.apache.org/confluence/display/FLEX/Compiling+Apache+Flex+for+different+Locales+and+different+versions+of+the+Flash+Player
How to run Mustella:
https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview
To make it easier to track the progress of testing, there is also a table
that shows which version/platform has been tested. Please take a look at
the pages, follow the steps, compile and then run Mustella for as many
versions as you can.
****A complete run of Mustella takes hours, so it would be better to plan
for an overnight run****
Please keep in mind that you dont need to be a committer to help out with
this very important step before our next release.
If you want to help,
you can directly edit the Wiki to add your name into the corresponding row
(if you have write access to the Wiki)
or
you can reply to this thread and I will add your name to the woki (if you
dont have write access to the Wiki)
Please feel free to respond with questions, if any.
Thanks,
Om
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Om <bi...@gmail.com>.
On Dec 18, 2012 2:27 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> Hi,
>
> > I would say that it is up to him (Justin, your thoughts?) I am all for
> > releasing sooner than later, but we need to follow the steps in the
right
> > order.
>
> Given that most users of the SDK are going to use the default of FP
11.1/AIR 3.4 we needs test that on windows/OSX, everything else is nice to
have.
>
I think you mean 11.4/3.4, right?
> I don't think we need to drop support for older versions of the flash
player, just state that they have not been fully tested and that there may
be some unknown issues.
>
Do you want to take a stab at modifying the README reflecting this
sentiment?
> Thanks,
> Justin
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
On 12/18/12 2:26 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I would say that it is up to him (Justin, your thoughts?) I am all for
>> releasing sooner than later, but we need to follow the steps in the right
>> order.
>
> Given that most users of the SDK are going to use the default of FP 11.1/AIR
> 3.4 we needs test that on windows/OSX, everything else is nice to have.
FP 11.1 and AIR 3.4 is a swf-version mismatch, isn't it? Anyway, we should
run SWCs built with that version against the latest player so we can try to
catch an serious behavior issues upfront. I'll do that this week sometime
(of course, it assumes the Projector player has the same behavior as the
browser plugins).
>
> I don't think we need to drop support for older versions of the flash player,
> just state that they have not been fully tested and that there may be some
> unknown issues.
>
> Thanks,
> Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would say that it is up to him (Justin, your thoughts?) I am all for
> releasing sooner than later, but we need to follow the steps in the right
> order.
Given that most users of the SDK are going to use the default of FP 11.1/AIR 3.4 we needs test that on windows/OSX, everything else is nice to have.
I don't think we need to drop support for older versions of the flash player, just state that they have not been fully tested and that there may be some unknown issues.
Thanks,
Justin
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Carol Frampton <cf...@adobe.com>.
On 12/18/12 3 :30PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
>On 12/18/12 12:21 PM, "Om" <bi...@gmail.com> wrote:
>
>>
>>
>> If we want to just get it out the door (I am not sure why we'd want to
>>do
>> it that way), we should update the README to not say we support these
>>other
>> flash player versions.
>>
>I was thinking we'd have more general language that various combinations
>have been tried and are known to work.
>>
>>>>
>>>> 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.
>>>
>>
>>
>> Sounds like a bad idea. We dont lock the develop branch. What if
>>someone
>> changes the tests in develop that make it incompatible with the code in
>>the
>> RC that was cut.
>Lately, I've been thinking that mustella is stable enough to be
>centralized
>instead of having a copy in each branch. We'd have to have some facility
>for dealing with branch-specific tests, but the vast majority is stable
>enough to only need a single copy. It would probably make us less likely
>to
>make incompatible changes going forward as well.
>>
>
>>>> 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.
>>>
>>
>> I would say that it is up to him (Justin, your thoughts?) I am all for
>> releasing sooner than later, but we need to follow the steps in the
>>right
>> order. I would say the right order is:
>>
>> a) Test with all versions of runtimes we want to support - on the
>>develop
>> branch
>> b) Fix issues as necessary
>> c) If we decide that a certain version of flash player is too costly to
>> support indicate that we dont support it in the README (hopefully we
>>drop
>> the older versions first)
>> d) Cut a release branch
>> c) Test release branch with preferred version (ex. FP 11.4 + AIR 3.4)
>> d) Cut an RC
>> e) Folks test src and binary kits with real projects (and not
>>necessarily
>> Mustella tests) and whatever runtimes they want to work with.
>>
>That is in theory, the correct order, but IMO, we should just test a few
>combinations and vote.
At this point I agree with Alex. Also within the next few days I am going
to check in the Adobe.next DataGrid changes and there are some mustella
test updates which would definitely be incompatible with testing the
release. The point of the develop branch is that you don't shutdown all
development while producing a release. I think the real issue at this
point is that the mustella tests that go with the release are not in the
release branch.
Carol
>
>--
>Alex Harui
>Flex SDK Team
>Adobe Systems, Inc.
>http://blogs.adobe.com/aharui
>
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
On 12/18/12 12:21 PM, "Om" <bi...@gmail.com> wrote:
>
>
> If we want to just get it out the door (I am not sure why we'd want to do
> it that way), we should update the README to not say we support these other
> flash player versions.
>
I was thinking we'd have more general language that various combinations
have been tried and are known to work.
>
>>>
>>> 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.
>>
>
>
> Sounds like a bad idea. We dont lock the develop branch. What if someone
> changes the tests in develop that make it incompatible with the code in the
> RC that was cut.
Lately, I've been thinking that mustella is stable enough to be centralized
instead of having a copy in each branch. We'd have to have some facility
for dealing with branch-specific tests, but the vast majority is stable
enough to only need a single copy. It would probably make us less likely to
make incompatible changes going forward as well.
>
>>> 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.
>>
>
> I would say that it is up to him (Justin, your thoughts?) I am all for
> releasing sooner than later, but we need to follow the steps in the right
> order. I would say the right order is:
>
> a) Test with all versions of runtimes we want to support - on the develop
> branch
> b) Fix issues as necessary
> c) If we decide that a certain version of flash player is too costly to
> support indicate that we dont support it in the README (hopefully we drop
> the older versions first)
> d) Cut a release branch
> c) Test release branch with preferred version (ex. FP 11.4 + AIR 3.4)
> d) Cut an RC
> e) Folks test src and binary kits with real projects (and not necessarily
> Mustella tests) and whatever runtimes they want to work with.
>
That is in theory, the correct order, but IMO, we should just test a few
combinations and vote.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Om <bi...@gmail.com>.
On Tue, Dec 18, 2012 at 10:49 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 12/18/12 10:32 AM, "Om" <bi...@gmail.com> wrote:
>
> > On Tue, Dec 18, 2012 at 10:06 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >>
> >>
> >>
> >> On 12/18/12 9:50 AM, "Om" <bi...@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.
>
If we want to just get it out the door (I am not sure why we'd want to do
it that way), we should update the README to not say we support these other
flash player versions.
> >
> > 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.
>
Sounds like a bad idea. We dont lock the develop branch. What if someone
changes the tests in develop that make it incompatible with the code in the
RC that was cut.
> >
> >
> >
> >> 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.
>
I would say that it is up to him (Justin, your thoughts?) I am all for
releasing sooner than later, but we need to follow the steps in the right
order. I would say the right order is:
a) Test with all versions of runtimes we want to support - on the develop
branch
b) Fix issues as necessary
c) If we decide that a certain version of flash player is too costly to
support indicate that we dont support it in the README (hopefully we drop
the older versions first)
d) Cut a release branch
c) Test release branch with preferred version (ex. FP 11.4 + AIR 3.4)
d) Cut an RC
e) Folks test src and binary kits with real projects (and not necessarily
Mustella tests) and whatever runtimes they want to work with.
> >
> >> 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.
>
If we want to do this, we should not test against the mustella tests in
develop, but agains the mustella tests in the release branch. The release
branch is more protected than the develop branch. This should prevent
spurious test failures or false positives.
>
> >
> > 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 agree. I think for Flex 4.9, that should be FP 11.4 and AIR 3.4. It
seems that users like it better when we say we support the latest versions
of the runtimes. It does not matter that we dont use the APIs in these new
runtimes. But this would facilitate users to write code against the new
runtime features more easily.
> 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.
Yes, but that would be a safe gamble, IMHO.
> 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.
>
>
Agreed.
> > 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.
>
>
I think I confused the source kit with the binary kit. In your recipe, the
binary kit in the RC would be redundant because we expect people who vote
to create that kit themselves. But we should probably create a binary kit
anyways because we will definitely want to release the binaries as is (at
least for the installer to work properly)
Thanks,
Om
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
On 12/18/12 2:20 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> 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.
>
> Perhaps the way to look at this is what would a user of the SDK expect?
>
> Currently we are not packaging up the mustella tests with the release
> packages, this means that there's likely only a small window of time where all
> the mustella tests will work with the released package (due to ongoing changes
> to the tests).
Really, the existing tests should not be changing. New tests should be
added, but we might find a clever way to manage them so don't run tests that
don't have features in a particular release.
>
> How important is it for user of the SDK to be able to run the mustalla tests?
> If it not important then all that matters is that we can test a RC with some
> confidence and it doesn't matter what location those test are in. If it is
> important we should package the tests are part of the release (preferable in a
> separate zip IMO).
>
I think it is the former. Most folks who are not approving an RC probably
don't need to run mustella.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 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.
Perhaps the way to look at this is what would a user of the SDK expect?
Currently we are not packaging up the mustella tests with the release packages, this means that there's likely only a small window of time where all the mustella tests will work with the released package (due to ongoing changes to the tests).
How important is it for user of the SDK to be able to run the mustalla tests? If it not important then all that matters is that we can test a RC with some confidence and it doesn't matter what location those test are in. If it is important we should package the tests are part of the release (preferable in a separate zip IMO).
Thanks,
Justin
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
On 12/18/12 10:32 AM, "Om" <bi...@gmail.com> wrote:
> On Tue, Dec 18, 2012 at 10:06 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 12/18/12 9:50 AM, "Om" <bi...@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
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Carol Frampton <cf...@adobe.com>.
On 12/18/12 1 :32PM, "Om" <bi...@gmail.com> wrote:
>On Tue, Dec 18, 2012 at 10:06 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 12/18/12 9:50 AM, "Om" <bi...@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.
I don't disagree and what you said is what I would have done. I would go
so far as to say I would have done a lot of this before I even cut a
release branch but the fact remains there is a VOTE going on.
>
>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.
>
Well all the same testing, or at least some of it should happen on the RC
as well to make sure everything was built and packaged properly.
Carol
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Om <bi...@gmail.com>.
On Tue, Dec 18, 2012 at 10:06 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 12/18/12 9:50 AM, "Om" <bi...@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.
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.
> 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.
> 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.
Also, the RC is baked with a version of flash player. 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.
> Prerequisites:
> Ant
> AIR SDK
> PlayerGlobal.swc
> HTTP server (assumes port 80, if you need to use 8080, then add
> -addArg=-include=Localhost8080 to mustella runs.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
> HTTP server (assumes port 80, if you need to use 8080, then add
> -addArg=-include=Localhost8080 to mustella runs.
Sorry, should be:
-addArg=-includes=Localhost8080
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
On 12/18/12 11:18 AM, "Carol Frampton" <cf...@adobe.com> wrote:
>> -Set FLEX_HOME environment variable to the folder
>> (FLEX_HOME=c:/apacheflex4.9). Note the forward slash for Cygwin.
>
> I don't think this is needed. sdk.dir/bin/mxmlc will use the directory it
> is in for FLEX_HOME if FLEX_HOME isn't set
>
Maybe. The key is to verify that in the compilation of the SWFs the output
says it is using the flex-config.xml from the RC folder and not the develop
branch. That doesn't show up until after the precompiles happen so you
might want to test on a single folder or script first before launching -all.
If you already have a FLEX_HOME, then I think you will need to change it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Carol Frampton <cf...@adobe.com>.
>
>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.
>
>My recipe (on Win, will try to run Mac tonight):
>
>-Download the RC.
>-Unzip to a folder (c:\apacheflex4.9).
This will become sdk.dir in mustella/local.properties seen in a later step
below.
>-Change the build.properties if you are trying different player version
Alternatively run ant with --Dplayerglobal.version=11.1 -Dlocale=en_AU
[targets] with version and locale replaced with whatever you want.
>-Setup the required environment variables
If you use env.properties, sync develop/mustella/build.xml and set
env.properties in the sdk.dir (c:\apacheflex4.9). Prior to the bug fix I
just made you would have to set env.properties in develop.
>-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.
I don't think this is needed. sdk.dir/bin/mxmlc will use the directory it
is in for FLEX_HOME if FLEX_HOME isn't set
>-Change to develop branch's mustella folder
>-Uncomment and edit local.properties to point sdk.dir to c:/apacheflex4.9
[optional] In the mustella directory run "ant echo-info" to check sdk.dir
and FLASHPLAYER_DEBUGGER are what you think they should be.
>-run ./mini_run.sh -all
>-run ./mini_run.sh -failures -rerun
>
>Prerequisites:
>Ant
>AIR SDK
>PlayerGlobal.swc
>HTTP server (assumes port 80, if you need to use 8080, then add
>-addArg=-include=Localhost8080 to mustella runs.
>
>
>--
>Alex Harui
>Flex SDK Team
>Adobe Systems, Inc.
>http://blogs.adobe.com/aharui
>
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
On 12/18/12 9:50 AM, "Om" <bi...@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.
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.
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
Prerequisites:
Ant
AIR SDK
PlayerGlobal.swc
HTTP server (assumes port 80, if you need to use 8080, then add
-addArg=-include=Localhost8080 to mustella runs.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Carol Frampton <cf...@adobe.com>.
On 12/18/12 12 :50PM, "Om" <bi...@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.
Since there is an open VOTE thread out there I agree with Alex that the RC
source kit should be used.
Carol
>
>Om
>On Dec 18, 2012 9:35 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 12/18/12 12:37 AM, "Om" <bi...@gmail.com> wrote:
>>
>> >
>> > Just to be clear, we should all be testing on the* 4.9 release
>>branch*:
>> >
>> Shouldn't we really be testing the RC?
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Om <bi...@gmail.com>.
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.
Om
On Dec 18, 2012 9:35 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 12/18/12 12:37 AM, "Om" <bi...@gmail.com> wrote:
>
> >
> > Just to be clear, we should all be testing on the* 4.9 release branch*:
> >
> Shouldn't we really be testing the RC?
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Justin Mclean <ju...@classsoftware.com>.
Do an ant checkintests and you'll see
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Erik de Bruin <er...@ixsoftware.nl>.
In the table on the Wiki page for our test there is a column 'Checkin
tests pass'. What test does this refer to?
EdB
On Tue, Dec 18, 2012 at 9:37 AM, Om <bi...@gmail.com> wrote:
> Thanks Erik, Fred, Alex and Nick who have volunteered so far!
>
> Others, there are still a lot of combinations available for testing. If
> you haven't had a chance to dig into Apache Flex and get your environment
> set up, this is a great time to start :-)
>
> Just to be clear, we should all be testing on the* 4.9 release branch*:
>
> https://svn.apache.org/repos/asf/incubator/flex/sdk/branches/release4.9
>
> And let us stick to *en_US *for now. It seems that other locales cannot be
> tested easily. More on that later.
>
> Thanks,
> Om
>
> On Tue, Dec 18, 2012 at 12:18 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> On it, starting with 10.2 on OS X.
>>
>> EdB
>>
>>
>>
>> On Tue, Dec 18, 2012 at 1:05 AM, Om <bi...@gmail.com> wrote:
>> > Justin has been working hard on getting Flex 4.9 into shape for a
>> release.
>> > He has also made it possible to easily switch between different versions
>> > of Flash Player while compiling the SDK.
>> >
>> > This is where you come in. Before we release, it would be great if we
>> can
>> > compile and run the Mustella test suite against each version of the Flash
>> > Player we want to support. Here are the detailed instructions on how to
>> > switch between Flash Player versions before compiling the SDK:
>> >
>> > How to compile Flex for different versions of Flash Player:
>> >
>> https://cwiki.apache.org/confluence/display/FLEX/Compiling+Apache+Flex+for+different+Locales+and+different+versions+of+the+Flash+Player
>> >
>> > How to run Mustella:
>> > https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview
>> >
>> > To make it easier to track the progress of testing, there is also a table
>> > that shows which version/platform has been tested. Please take a look at
>> > the pages, follow the steps, compile and then run Mustella for as many
>> > versions as you can.
>> > ****A complete run of Mustella takes hours, so it would be better to plan
>> > for an overnight run****
>> >
>> > Please keep in mind that you dont need to be a committer to help out with
>> > this very important step before our next release.
>> >
>> > If you want to help,
>> > you can directly edit the Wiki to add your name into the corresponding
>> row
>> > (if you have write access to the Wiki)
>> > or
>> > you can reply to this thread and I will add your name to the woki (if you
>> > dont have write access to the Wiki)
>> >
>> > Please feel free to respond with questions, if any.
>> >
>> > Thanks,
>> > Om
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Others, there are still a lot of combinations available for testing. If
> you haven't had a chance to dig into Apache Flex and get your environment
> set up, this is a great time to start :-)
>
> Just to be clear, we should all be testing on the* 4.9 release branch*:
> https://svn.apache.org/repos/asf/incubator/flex/sdk/branches/release4.9
Testing on multiple platforms is good, but don't forgot the vote is about the the source bundles in RC4.
If you're testing on the release branch that mean you're basically testing RC5. However given that the changes between RC4 and RC5 are likely to be limited to a few minor build scripts and README changes it's IMO not a big issue.
We now have a slight issue in that mustella tests have been updated in develop but not updated in release. Even if I had all of the revision numbers I'm not sure it would be easy to merge the required changes across to get all mustella tests to pass, especially as other changes have also gone into the develop branch. Any suggestions on how to resolve this?
Thanks,
Justin
Re: We need your help testing Flex 4.9 with various Flash Player
versions
Posted by Alex Harui <ah...@adobe.com>.
On 12/18/12 12:37 AM, "Om" <bi...@gmail.com> wrote:
>
> Just to be clear, we should all be testing on the* 4.9 release branch*:
>
Shouldn't we really be testing the RC?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Om <bi...@gmail.com>.
Thanks Erik, Fred, Alex and Nick who have volunteered so far!
Others, there are still a lot of combinations available for testing. If
you haven't had a chance to dig into Apache Flex and get your environment
set up, this is a great time to start :-)
Just to be clear, we should all be testing on the* 4.9 release branch*:
https://svn.apache.org/repos/asf/incubator/flex/sdk/branches/release4.9
And let us stick to *en_US *for now. It seems that other locales cannot be
tested easily. More on that later.
Thanks,
Om
On Tue, Dec 18, 2012 at 12:18 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> On it, starting with 10.2 on OS X.
>
> EdB
>
>
>
> On Tue, Dec 18, 2012 at 1:05 AM, Om <bi...@gmail.com> wrote:
> > Justin has been working hard on getting Flex 4.9 into shape for a
> release.
> > He has also made it possible to easily switch between different versions
> > of Flash Player while compiling the SDK.
> >
> > This is where you come in. Before we release, it would be great if we
> can
> > compile and run the Mustella test suite against each version of the Flash
> > Player we want to support. Here are the detailed instructions on how to
> > switch between Flash Player versions before compiling the SDK:
> >
> > How to compile Flex for different versions of Flash Player:
> >
> https://cwiki.apache.org/confluence/display/FLEX/Compiling+Apache+Flex+for+different+Locales+and+different+versions+of+the+Flash+Player
> >
> > How to run Mustella:
> > https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview
> >
> > To make it easier to track the progress of testing, there is also a table
> > that shows which version/platform has been tested. Please take a look at
> > the pages, follow the steps, compile and then run Mustella for as many
> > versions as you can.
> > ****A complete run of Mustella takes hours, so it would be better to plan
> > for an overnight run****
> >
> > Please keep in mind that you dont need to be a committer to help out with
> > this very important step before our next release.
> >
> > If you want to help,
> > you can directly edit the Wiki to add your name into the corresponding
> row
> > (if you have write access to the Wiki)
> > or
> > you can reply to this thread and I will add your name to the woki (if you
> > dont have write access to the Wiki)
> >
> > Please feel free to respond with questions, if any.
> >
> > Thanks,
> > Om
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: We need your help testing Flex 4.9 with various Flash Player versions
Posted by Erik de Bruin <er...@ixsoftware.nl>.
On it, starting with 10.2 on OS X.
EdB
On Tue, Dec 18, 2012 at 1:05 AM, Om <bi...@gmail.com> wrote:
> Justin has been working hard on getting Flex 4.9 into shape for a release.
> He has also made it possible to easily switch between different versions
> of Flash Player while compiling the SDK.
>
> This is where you come in. Before we release, it would be great if we can
> compile and run the Mustella test suite against each version of the Flash
> Player we want to support. Here are the detailed instructions on how to
> switch between Flash Player versions before compiling the SDK:
>
> How to compile Flex for different versions of Flash Player:
> https://cwiki.apache.org/confluence/display/FLEX/Compiling+Apache+Flex+for+different+Locales+and+different+versions+of+the+Flash+Player
>
> How to run Mustella:
> https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview
>
> To make it easier to track the progress of testing, there is also a table
> that shows which version/platform has been tested. Please take a look at
> the pages, follow the steps, compile and then run Mustella for as many
> versions as you can.
> ****A complete run of Mustella takes hours, so it would be better to plan
> for an overnight run****
>
> Please keep in mind that you dont need to be a committer to help out with
> this very important step before our next release.
>
> If you want to help,
> you can directly edit the Wiki to add your name into the corresponding row
> (if you have write access to the Wiki)
> or
> you can reply to this thread and I will add your name to the woki (if you
> dont have write access to the Wiki)
>
> Please feel free to respond with questions, if any.
>
> Thanks,
> Om
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl