I've been toying around with versioning schemes, and I've decided that the master branch should really not just be a place to merge new versions. master, itself, should be the latest development/deployable version, not anything else.
The problem, of course, lies in our definition of deployability. If we speak simply of deploying by uploading to RubyGems, then technically the versioning system I switched to works; creating a version branch and using that as the base for each release makes sense, then merging that branch and releasing on the merge commit.
It's much better to do otherwise, however, by simply merging feature/fix branches into master as they come along, versioning appropriately. And that is how it will go.
I've been toying around with versioning schemes, and I've decided that the
masterbranch should really not just be a place to merge new versions.master, itself, should be the latest development/deployable version, not anything else.The problem, of course, lies in our definition of deployability. If we speak simply of deploying by uploading to RubyGems, then technically the versioning system I switched to works; creating a version branch and using that as the base for each release makes sense, then merging that branch and releasing on the merge commit.
It's much better to do otherwise, however, by simply merging feature/fix branches into
masteras they come along, versioning appropriately. And that is how it will go.