Yep, this is exactly what we do at work for all of our releases. It works quite well.
In practice, we always tag every release and only create a branch if there are bugs reported against a previous release. If there is no branch at the time an issue is reported, we create one at that time off of the tag and then do our bug fixes in this 'lazily-created' branch. The only benefit this provides is that the number of branches tends to be smaller over time, making it easier to browse the SVN branches directory. But I certainly have no problems with always creating a branch no matter what if that's what people prefer. Any preferences? Les On Mon, Dec 7, 2009 at 3:40 PM, Kalle Korhonen <[email protected]> wrote: > On Mon, Dec 7, 2009 at 12:23 PM, Alan D. Cabrera <[email protected]> wrote: >> If one uses a branch name branches/1.x and let's say that 1.0, 1.1, and 1.2 >> have been released, what do you do when you need to patch 1.1? When you > > When 1.1.0 is released, a 1.1.x branch is created (or it's created > later from 1.1.0 tag when needed). Once we release 1.0.0, we could > either immediately create 1.0.x branch and prepare trunk for 1.1.0 > development, or we prepare trunk for 1.0.1 development and branch the > same way later as needed. > >> make this 1.x branch what goes into trunk? > > If there's a 1.x branch, it implies that trunk has already moved to > 2.x (following the release branch pattern - the version "farthest out" > is in the trunk). The x in the branch name denotes "the trunk for all > versions of <version>.x" > > Kalle >
