Mark Brouwer wrote:
So ongoing development (latest and greatest) takes place in the trunk, sustaining development for a particular release (m.n.?) will take place in the maintenance branch. "Golden" reference only release are branched in /tags/release_{m.n.r}//trunk | | |---------- /maintenance/release_2.1/ | \ | \ | \ | \ ------- /tags/release_2.1.0/ | \ | \ | \ | \ ------- /tags/release_2.1.1/ | \ | | | |--------- /maintenance/release_2.2/ | \ | \ | \ ------- /tags/release_2.2.0/ | \ | | | | |--------- /maintenance/release_3.0/ | \ | \ | \ ------- /tags/release_3.0.0/ | \ | Applying the branching strategy as above will result in the ability to keep the pace in the trunk without influencing the codebase that is about to be released. My experience is that between feature ready and a final release there are always these last minutes issues that pop up need to be resolved, if not that is great, if so there is a place for it by default.
I think we should decide about our branching strategy, this I believe is something that needs to be resolved before going further. Are there any reasons why the above branching strategy is not going to work or is a bad thing. I'm not talking about ad-hoc branching or branching to enable collaborative development which could branch from both the trunk and the maintenance lines and flow back to their origin. -- Mark
