On Tue, Dec 18, 2012 at 10:49 AM, Alex Harui <aha...@adobe.com> wrote:
> > > > 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. > 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
