Hi, > Imagine if we really get going and have lots of new stuff coming in. I > can't see how we could keep trunk stable enough. Not mater where you put it that always going to be the issue. With CI (especially if we can get Mustella running off check ins) it's less of an issue.
> Plus, I'm not sure how many non-committers are going to pull from trunk; No many but once we get nightly builds up and running they might. (BTW we do currently have a basic nighty build via Jenkins.) > I think they would use official releases. And I'm not sure if they'd spend > much time with stuff > labelled experimental. Perhaps not but I think some would and at the very least it provide a clue to what might be merged into the other namespaces. > I still like the 3-tier approach. Really experimental stuff goes in the > whiteboard. No issue with that. However users of the SDK are likely to ignore anything that is here. It will take considerable effort on there part to be able to use it. > We would ask the committers and other interested folks to generally work out > of the unstable > branch. For work in progress I assume you mean? > That would be where I would be fixing bugs Why shouldn't bug fixes be put into trunk were they would be most useful? > I probably wouldn't spend time syncing trunk until some release manager says > they want > to cut a release. Having worked on many large SVN projects over the years I would strongly recommend against that approach. In my experience: 1. Tend to cause large number of merge issues 2. Merging branches is SVN is sometimes problematic 3. Integration issues - just before a release everyone tries to merge with trunk and lots ends up broken. 4. Continuous integration works best if all changes are checked into trunk (IMO). IMO check into trunk often as you can work best. Yes occasionally the build may be broken/trunk not in a fit state but with a CI system we'll know about it and be able to fix or revert as required. Thanks, Justin
