On 12/18/12 1 :32PM, "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. 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
