Clarify release and version developper guidelines

[haubourg]

Hi all, version management and release policy has know various pratices up to now. In 2017, any pull request introducing data model changes created a new version. Releases were handled by hand, and not every version had an associated release.

This led to some communication issues with the general board, because minor versions (aka bugfix versions) where used as roadmap targets

It also leaded to version conflicts of all concurrent pull requests

@elemoine @sylvainbeo and @lbartoletti have a proposal for a clear and shared worflow.

Version and release management policy

• Version Roadmap for new features must be shared on the tracker and with the general committee. Issues must be opened and tagged using labels (1.4 , 1.5).
• Do not create a version for each code change.
• Versions will group different code change and must be discussed with the released manager.
• It is possible to multiple Delta files for one "version-release" Ex: delta_1.3.2_0001_one_change , delta_1.3.2_0002_another_change
• Each new version will systematically have a release. A release is materialized by a git tag
• travis-CI automatically deploys a release when the tag is pushed AND the tests succeed
• Data administrators must NEVER work on master branch, but use release. The rationale behind that is that the latest version in master branch changes until the release, so it is not a reliable version tag . This means for git user they ahve to fetch remote tags and checkout to the desired release using git checkout tag_number

@3nids and @ponceta, We'd like a shared policy here. Do you agree with that?

[haubourg]

No reaction ? Well last PR by @tudorbarascu and @elemoine follow that guidelines. I must say that allowing multiple sorted delta files this is a lot clearer and easier to use this way for me as a reviewer.

[haubourg]

Tested and approved when release 1.3.2