On 12/18/12 3 :30PM, "Alex Harui" <aha...@adobe.com> wrote:
> > > >On 12/18/12 12:21 PM, "Om" <bigosma...@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 >
