flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject Testing strategy (was: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch))
Date Thu, 09 Aug 2012 05:00:31 GMT
Why all the focus on branching strategies? It makes more sense to focus on a testing strategy.
We need an 'ant tests' and a requirement that it pass for all changes to trunk.

Didn't the mustella tests get submitted? What more do we need other than an easy way to run

- Gordon

Sent from my iPad

On Aug 8, 2012, at 7:21 PM, "Om" <bigosmallm@gmail.com> wrote:

> On Wed, Aug 8, 2012 at 6:40 PM, Justin Mclean <justin@classsoftware.com>wrote:
>> Hi,
>>> I would use the name "alt-trunk" instead of "unstable" for the other
>>> branch.  Every rule that applies to trunk would apply to the alt-trunk
>>> branch.
>> The issue I see is having one single branch not the name. You would be
>> fine with the multi step step check in process (with unresolved issues) as
>> describe below every time you wanted to make a change?
> If we cannot guarantee that the branch is stable everytime anyone wants to
> make a change, how can we do it in trunk?  What special properties that
> trunk have that makes it easier there?
> If I check in something that breaks the build or causes numerous issues
> into alt-trunk, I will have to either pull it out or fix it in alt-trunk
> itself.  Trunk does not even come into picture here.
> Only when we are closer to a release, we will merge alt-trunk into trunk.
> It would be a much smoother process then because we would have brought
> alt-trunk to stability before we attempt the merge into trunk.
>>> Remember that if we do all the development in trunk, we would have
>>> to do the same thing except that it would be a much bigger problem
>> because
>>> we dont have any place to go when we screw things up.
>> How about svn revert?
> That is the command we would use, yes.  But what if we dont find out the
> issues in time?  What if we find out multiple huge issues when it is time
> to cut a release.  The complexity that would ensue is something we are not
> set up for now.
> Maybe after a couple of releases, yes.
>> When are happy with alt-trunk's state, we merge alt-trunk into trunk and
>> cut a release off of trunk.
>> So we would have to have a code freeze while we sort out merge issues and
>> the like?
> Yes.
>> How would you not include the changes you did not want to go into trunk?
>> How would we do it if everyone checks into trunk directly?
>> Just want to make it clear what people are agreeing to.
> Let's use alt-trunk as a training ground.  Lets get it right there and we
> can move to working directly off of trunk.
> Om

View raw message