Increment "develop" version when branching release

[judgeaxl]

This issue has been broken out of the discussion here: #632

The current behavior is to use the "-unstable.N" pre-release revision to ensure builds from develop are considered newer than those on release branches that have not yet been merged back to develop.

Example:

A-B-C (develop)
   \D-E (release/0.1)

In the above graph, build A-C would get the versions 0.1.0-unstable.1-3, and D and E would get 0.1.0-rc.1-2. A-C would all be considered newer than D and E. Not until release/0.1 is merged back into develop does develop's version get bumped to 0.2.0. I find this counter-intuitive. After all, I've branched the release, why is it still being developed (as opposed to just being stabilized), and why are those builds considered newer than the release itself?

One might argue that deleting a release branch, after concluding the release should be cancelled, would then cause develop to drop back(!) to the previous minor version, but I don't think one should ever delete release branches like that. 1) it causes the problem I just mentioned, and 2) if you had at least one build from that release branch before deleting it, and then re-create the same release, there's nothing guarding you from generating the same 0.1.0-rc.1 version again, which would also become confusing. You could of course tag/configure develop to stay at 0.2.0, but that feels like a bit of a kludge, and you still shouldn't re-create releases. There's nothing in SemVer that says you cannot skip a version, AFAIK, so this wouldn't invalidate anything.

If this was to be changed, and develop were to be bumped on branch, then the -unstable tag should be replaced with something that sorts before -rc, but I haven't got a suggestion that is better than the one in #632.

[o-o00o-o]

I agree, I think this approach makes a lot of sense. See further discussion in #632