Reformat docs/design/versioning.md (#2057)

Author: wangkuiyi

docs/designs/versioning.md

@@ -1,20 +1,32 @@
 # Versioning
 
-For better managing and releasing code, here is a summary about the versioning story of ElasticDL. Some previous discussions can be found [here](#1121).
+For better managing and releasing code, here is a summary about the versioning
+story of ElasticDL. Some previous discussions can be found [here](#1121).
 
 ## Branches
 
 There are three different type branches:
-- **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 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 merge info `develop` branch.
-- **release** branches: branch off from the `develop` branch. When the `develop` branch reaches the desired state of a new release, cut off a new release branch, and start to publish new versions there. Release branches will be kept.
-
-For version numbers, we follow the [Semantic Versioning 2.0.0](https://semver.org/ with style MAJOR.MINOR.PATCH (e.g. 0.2.1). For each MAJOR.MINOR, we keep a corresponding `release` branch (named `branch-x.y`), and each following patch version x.y.z is released from it.
 
+- **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 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 merge info `develop` branch.
+- **release** branches: branch off from the `develop` branch. When the `develop`
+  branch reaches the desired state of a new release, cut off a new release
+  branch, and start to publish new versions there. Release branches will be
+  kept.
+
+For version numbers, we follow the Semantic Versioning
+[2.0.0](https://semver.org) with style MAJOR.MINOR.PATCH (e.g. 0.2.1). For each
+MAJOR.MINOR, we keep a corresponding `release` branch (named `branch-x.y`), and
+each following patch version x.y.z is released from it.
 
 ## Feature Development
 
-New features and bugfixes are developed in `feature` branches. Make sure you work with the latest version of `develop` branch.
+New features and bugfixes are developed in `feature` branches. Make sure you
+work with the latest version of `develop` branch.
 
 ```bash
 # Start a new feature branch from develop branch
@@ -28,7 +40,9 @@ $ git checkout develop
 $ git branch -D feature1
 ```
 
-Here is the [tutorial](https://help.github.com/en/articles/creating-a-pull-request#changing-the-branch-range-and-destination-repository) on how to open a pull request.
+Here is the
+[tutorial](https://help.github.com/en/articles/creating-a-pull-request#changing-the-branch-range-and-destination-repository)
+on how to open a pull request.
 
 ## Releasing
 
@@ -48,7 +62,11 @@ $ git push origin branch-0.1
 # A detailed instruction is available at https://packaging.python.org/tutorials/packaging-projects/
 ```
 
-So now we have v0.1.0rc0 ready to use. Test out this version. If any issues found, get them fixed in `develop` branch, merged into `branch-0.1` branch, and repeat the aforementioned steps to publish a new release candidate version. We keep releasing `rc` version until no further issues found. At that time, release the official `v0.1.0` version.
+So now we have v0.1.0rc0 ready to use. Test out this version. If any issues
+found, get them fixed in `develop` branch, merged into `branch-0.1` branch, and
+repeat the aforementioned steps to publish a new release candidate version. We
+keep releasing `rc` version until no further issues found. At that time, release
+the official `v0.1.0` version.
 
 ```bash
 $ git checkout -b branch-0.1 develop
@@ -61,7 +79,11 @@ $ git push origin branch-0.1
 $ git tag v0.1.0 -a
 $ git push origin v0.1.0
 ```
-Note that for creating new releases and tags, you can also do from the [website](https://github.com/sql-machine-learning/elasticdl/releases).
 
+Note that for creating new releases and tags, you can also do from the
+[website](https://github.com/sql-machine-learning/elasticdl/releases).
 
-For cases where the `release` branch already exists (for example when releasing 0.1.1 and `branch-0.1` is already there), just reuse that `release` branch and merge required commits from `develop` branch to the corresponding `release` branch.
+For cases where the `release` branch already exists (for example when releasing
+0.1.1 and `branch-0.1` is already there), just reuse that `release` branch and
+merge required commits from `develop` branch to the corresponding `release`
+branch.