Migrate docs for release procedures

Also, add descriptions for `GO111MODULE` into `Getting started` and `Dependency management`
And bump docker version requisites to 1.13.1+.

docs/developer/dependency-management.md

@@ -5,7 +5,8 @@
 
 ## Go dependencies
 
-- Use [go mod](https://github.com/golang/go/wiki/Modules) as dependency manager. 
+- Use [go mod](https://github.com/golang/go/wiki/Modules) as dependency manager.
+- Run `export GO111MODULE=on` to enable `go mod`. 
 - Run `go mod tidy` before sending any changes.
 - Use only official releases, avoid using master versions.
 

docs/developer/getting-started.md

@@ -6,8 +6,9 @@ This document describes how to setup your development environment.
 
 Make sure the following software is installed and added to the $PATH variable:
 
-* Docker 1.10+ ([installation manual](https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/))
+* Docker 1.13.1+ ([installation manual](https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/))
 * Golang 1.12.0+ ([installation manual](https://golang.org/dl/))
+    * Dashboard uses `go mod` for go dependency management, so enable it with running `export GO111MODULE=on`.
 * Node.js 11+ and npm 6+ ([installation with nvm](https://github.com/creationix/nvm#usage))
 * Gulp.js 4+ ([installation manual](https://github.com/gulpjs/gulp/blob/master/docs/getting-started/1-quick-start.md))
 

docs/developer/release-procedures.md

@@ -1,6 +1,37 @@
 # Release procedures
 
-___It will be moved soon, for now you can [visit Wiki](https://github.com/kubernetes/dashboard/wiki/Release-procedures).___
+## Official releases
+
+After significant improvements have been done it is worth to release a new version. In order to do so just follow the steps described below:
+
+1. Test everything twice on Docker image and `npm run start:prod`.
+2. Send a pull request that increases version numbers in all files. Follow versioning guidelines. Files to keep in sync are listed below:
+    * `package.json` and `package-lock.json`
+    * `aio/gulp/conf.js`
+    * YAML files from `aio/deploy`
+3. Get the pull request reviewed and merged.
+4. Create a git [release](https://github.com/kubernetes/dashboard/releases/) tag for the merged pull request. Release description should include a changelog.
+5. Update add-ons on the [Kubernetes](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dashboard) repository. If the update is minor, all that needs to be done is to change image version number in the main controller config file (`dashboard-controller.yaml`), and other configs, as described in the header of the config. If the release is major, this needs coordination with Kubernetes core team and possibly alignment with the schedule of the core.
+6. Update addon config in the [minikube](https://github.com/kubernetes/minikube/tree/master/deploy/addons) repository.
+7. Update addon config in the [kops](https://github.com/kubernetes/kops/tree/master/addons/kubernetes-dashboard) repository.
+
+Official release procedures are done by CI after successful TAG build automatically, that are pushed to [`kubernetesui/dashboard*`](https://hub.docker.com/u/kubernetesui) repositories.
+
+### Versioning guidelines
+
+Kubernetes Dashboard versioning follows [semver](http://semver.org/) in spirit. This means that it uses `vMAJOR.MINOR.PATCH` version numbers, but uses UX and consumer-centric approach for incrementing version numbers.
+
+1. Increment MAJOR when there are breaking changes that affect user's workflows or the UX gets major redesign.
+2. Increment MINOR when new functionality is added or there are minor UX changes.
+3. Increment PATCH in case of bug fixes and minor new features.
+
+Versions `0.X.Y` are reserved for initial development and may not strictly follow the guidelines.
+
+## Development releases
+
+There is no need to do anything at all after everything was set up and now the whole process is automated.
+
+On every successful master build CI provides development releases, that are pushed to [`kubernetesdashboarddev/dashboard*`](https://hub.docker.com/u/kubernetesdashboarddev) repositories. Each build produces one image for each architecture. The images are tagged with `head`.
 
 ----
 _Copyright 2019 [The Kubernetes Dashboard Authors](https://github.com/kubernetes/dashboard/graphs/contributors)_