> > > > My ultimate first choice would be to get this project on Git. :) > Maybe I'm missing something, but my read of the article was that the > "develop" branch was the same as "unstable" and is even more restrictive > about checkins to trunk than I was thinking. It just seems to want to use > even more branching. How does that make things better? > > The "develop" branch is where things get integrated and stabilized. The "develop" branch also always has all of the latest fixes that are ready to be integrated into the next release.
When its time for a release you make a "release" branch to make the changes to the source required for a new version, update version number, etc. While this "release" is being prepared development can continue in parallel for the next stuff. This would happen by going to the "develop" branch and making a new "feature" branch. New stuff starts getting developed here. Now the release can be prepared while new features and fixes are being developed as well. When the "release" branch is ready to actually be released, version numbers updated etc, the release branch is tagged "v.1.1". Then the release branch is merged to "develop" to get it up to date w/ the release changes. Then the release branch is merged to "trunk/master" which triggers a Jenkins build and a new version of the product. When the "feature" branch is stable, it is ready for the next release, so it is merged back into the "develop" branch and stabilized. When all the "feature" branches have been merged back to "develop" and its ready for a new release you rinse and repeat the whole process. This approach works because it allows parallel development, off of baselines that are always easily found, because they're branched from either "develop" if its a new upcoming feature, or branched from a version tag if its a "hotfix" to an existing version. -omar
