I've been looking at the gitflow workflow a bit http://nvie.com/posts/a-successful-git-branching-model/, and it makes sense and is very similar to what I've done in the past. I've done things a little differently when it comes to releasing and hot fixing and wanted to ask about the advantage or disadvantage of they way gitflow branches vs how I've proposed.
Typically when I create a release branch, say for release 1.0.0, I'll name the release branch release-1.0.x, not release-1.0.0. Once I create the branch (but before the code is released), the version will be 1.0.0-SNAPSHOT for any last minute fixes. When I release, I create release version of 1.0.0, tag it and merger to master. Now rather than deleting the release branch, I increment the version to 1.0.1-SNAPSHOT. This effectively becomes a long-lived hot fix branch for the release 1.0.x series. If I find a bug in production, I'll fix it on this branch, cut a 1.0.1 release version and increment the version to 1.0.2-SNAPSHOT, and so on.
The downside is that release branch exists for as long as this release is the current release. The upside is that I don't need to create new hot fix branches if there's a bug, and the branch already exists.
So my question is am I missing any major issues here by not having the hot fix branches and doing it this way?