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 them? - Gordon Sent from my iPad On Aug 8, 2012, at 7:21 PM, "Om" <bigosma...@gmail.com> wrote: > On Wed, Aug 8, 2012 at 6:40 PM, Justin Mclean <jus...@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
