Add specification versioning- and release management instructions and checks

[lukpueh]

Fixes #73

• Add gitflow-based version- and release management instructions to the Versioning section of the README.

• Add links to "latest stable", "current draft", "new changes since latest stable" and "release history" of the specification in the header of the README document.
  (Note that the version number of the latest stable version of the specification is no longer shown in the README, which eliminates the need to update the README with every new release.)

• Add script to run on Travis upon a GitHub pull request, that checks that versioning- and release management rules are followed, and configure travis accordingly.

Reviewers may focus on the changes in README.rst.
The check_release.py-script and .travis.yml-configuration are only there to help us follow the version/release strategy.

[lukpueh]

I just configured branch restrictions for the master branch to:

• require one review approval before merging
• dismiss prior approvals when new commits are pushed
• require status check to pass before merge, i.e. check_release.py
• require branches to be up to date before merging

Repo administrator can still bypass any of these restrictions.

[lukpueh]

IMHO the next steps should be:

1. Review and merge this PR (despite failing travis check)
2. Create and merge a PR that removes TAP 3 and TAP 4 from the spec, i.e. removes 2 lines in section 1.5.4. (despite failing travis check)
   1. (Optionally merge in Clarify rollback attack prevention and fast-forward attack recovery #86 (despite failing travis check))
3. Make a formal 1.0.0 spec release, i.e. git tag v1.0.0
4. Henceforth require folks to follow the release/versioning strategy suggested by this PR and travis check to pass

After that the next steps will be to add TAP 4 and release 1.1.0, and add TAP 3 (#57) and release 2.0.0.

[lukpueh]

This is currently not verified by check_release.py, because the script is executed before the merge, and the tag should probably be created after the merge. It would be nice to automate tag or release creation.

[lukpueh]

Any thoughts, anyone?

[JustinCappos]

I agree this would be nice to automate.

[lukpueh]

Okay, I can look into it.

[JustinCappos]

It's slightly odd to me that the person sending a PR doesn't indicate minor vs major. Also, it sounds like those are getting intertwined in a way we may not want. What if we want to push a release with some backwards compat (minor version) changes but not others that are not backwards compatible? Do we disentangle these changes at that time?

[JustinCappos]

I'd prefer to have a model where there are major, minor, and patch branches and they interrelate in the way your master and draft branches do.

I like the overall approach though!

[lukpueh]

It's slightly odd to me that the person sending a PR doesn't indicate minor vs major.

I think the person who sends the PR should not be bothered with the question into what future release the submitted change goes, regardless of it being major, minor or patch. This is the task of the maintainer. Maybe I should add a note to this section that says maintainers may change the target of a pending PR?

Also, it sounds like those are getting intertwined in a way we may not want. What if we want to push a release with some backwards compat (minor version) changes but not others that are not backwards compatible? Do we disentangle these changes at that time?

Coordinating major and minor releases can still be done, either by holding back PRs from being merged into draft, or, if it's too late for that, by shuffling around the git history on draft. The consensus in #73 seemed to be that the operational simplicity of having one working branch, plus the option to directly patch master, outweighs the flexibility of multiple permanent draft branches.

I like the overall approach though!

Thanks.

[mnm678]

I agree with @lukpueh, we want to make PRs as simple as possible. As long as we merge draft into master regularly, I don't think that we will need any additional branches.

[trishankatdatadog]

LGTM, let's move this forward