Versioning story for ElasticDL

[ywskycn]

Currently we only have develop branch and some personal feature-development branches. We need to have a better story about the versioning. A reference: https://nvie.com/posts/a-successful-git-branching-model/.

[ywskycn]

Five different branches:

• master branch: the main branch where the source code always reflects a production-ready state.
• develop branch: the main branch where the source code always reflects a state with the latest delivered development changes for the next release.
• feature branches: branch off from the develop branch and must merge back into develop. Feature branches are used to develop new features.
• release branches (named release-*): branch off from develop, and must merge back into develop and master. When the develop branch reflects the desired state of a new release, cut off a new release branch.
• hotfix branches (named hotfix-*): branch off from master branch. For example, say version 1.2 is the current production release running live and causing troubles due to a severe bug. But changes on develop are yet unstable. We may then branch off a hotfix branch and start fixing the problem.

Some details about the release branches. For example, if we would like to cut off release-1.2 from the develop branch.

# Start the new branch
$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
# Use script to bump version, modify related files
$ ./bump-version.sh 1.2.0-rc1
# Commit changes
$ git commit -a -m "Bumped version number to 1.2.0-rc1"

Now we can start do more testings on 1.2.0-rc1 release, and can also create a tag for 1.2.0-rc1. If any issues/bugs found, fix in release-1.2 and also backport to develop branch (if needed), also remember to bump the rc number. When we finalize release-1.2, merge all code from release-1.2 into master branch, and tag the release.

# Finalize the version
$ ./bump-version.sh 1.2.0
$ git commit -a -m "Bumped version number to 1.2.0"
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.0

[terrytangyuan]

@ywskycn Would it be possible to remove "develop" branch and use "master" branch to reflect a state with the latest delivered development changes for the next release instead? From what I see, most projects on Github use master branch (also the default) for this purpose. I think whether "the source code always reflects a production-ready state" should be reflected by the release versions (e.g. major releases are always more stable and more production-ready than minor releases).

[terrytangyuan]

Another thing to add: once release branches are created, we also turn on protection in repo settings to prevent them from being accidentally deleted and enforce all changes through pull requests.

[ywskycn]

After some offline discussions, here is another simpler approach:

• develop (or trunk, master) branch: the main branch where the source code always reflects a state with the latest delivered development changes for the next release.
• feature branches: branch off from the develop branch and must merge back into develop. Feature branches are used to develop new features, and created/maintained by developers themselves. Feature branches will be deleted after code changes get merged into develop branch.
• release branches (named release-*): branch off from develop. When the develop branch reaches the desired state of a new release, cut off a new release branch. Release branches will be kept.

So, how to cut a new release:

# Start the new branch
$ git checkout -b release-1.2 develop
# Switched to a new branch "release-1.2"
# Use script to bump version, modify related files
$ ./bump-version.sh 1.2
# Commit changes
$ git commit -a -m "Bumped version number to 1.2"
# Build a rc version
$ git tag -a v1.2.0-rc0

For new features, we can always get PRs merged into develop branch.

For bug fixes for old release branches, we also get PRs merged into develop branch first, and then backport to release branches which need these PRs. For cases where bug only exists in some release branches, for example, the code that triggers the bug always be removed from develop, we can merge PRs to corresponding release branches.

cc @terrytangyuan @typhoonzero