Switch branching strategy to "git-flow"

I intend to switch the branching model of edn-java git-flow.

This entails:

master will be reset to point to the same revision as the 0.4.0 tag.
future commits on master will only be actual releases (not SNAPSHOT)
the develop branch takes over the role currently played by 'master', but will build as version develop-SNAPSHOT.
releases will be prepared on temporary release branches originating from develop, with merge back to develop and master.
we decide on the release branch which version the release in preparation will have.
merging a release branch to master is making a release. The resulting revision will be tagged accordingly.
feature branches originate on develop and merge back to develop.

The git-flow model strikes me as a clean way to manage branches.

It has the advantage, on git hub, that the branch users see by default 'master' will show them the README of most recent stable release.

One potential drawback is that there's a monotonicity to putting all releases on master.

Consider this hypothetical: we release 2.0.0 but need to continue maintenance of 1.1.x, for some time because it takes users a while to upgrade to 2.0.0. Git-flow doesn't make explicit allowances for this, but it seems it could be addressed by branching "master-1.1.x" from the last 1.1.x tag and treating it like a second "master" branch.

I don't consider it likely that I'll need to maintain two production versions of edn-java in parallel at this stage in its life cycle (or really, ever), so I think this potential drawback is acceptable.

bpsm / edn-java

Switch branching strategy to "git-flow" #29