I'm actually used to a process where master is the dirty bleeding edge and releases get branched off.
This is probably a more common approach to using Git (and how most projects do it on github in my experience).
New features are developed and tested in branches, and as the new feature is stable, you merge it in to master, then delete the feature branch.
Then, when the new features in master reach a point where they are stable, you tag the release, and keep going. Then you create your release based on the tag (which is basically just a branch).
This allows you to do updates easily to previous releases:
check out the tag of the release you want, cherrypick the commits from master, then create a new tag. For example, say you create a tag for v1.0.0, then you find a bug a month later after you have been working on new features for v1.1.0. So you fix the bug in master, then check out the previous tagged release, cherrypick the bug fix(es) you want from master, then create a new tag - so you end up with v1.0.1, which is just v1.0.0 + the only the bugfix commits from master. Then you go back to working on master, and when it's testing and "done" you tag it as your new version and the cycle repeats.
I'd recommend using this approach to make it easier for new developers to come on board and help out.