Prepare for 1.4.1: bump nodeup; add docs

This commit is contained in:
Justin Santa Barbara 2016-10-10 10:42:40 -04:00
parent 4bca0a37d1
commit 6eeb7bf596
4 changed files with 33 additions and 7 deletions

9
HISTORY.md Normal file
View File

@ -0,0 +1,9 @@
## 1.4.1
* Fix dns-controller when multiple HostedZones with the same name
* Initial support for CentOS / RHEL7
* Initial k8s-style API & examples
## 1.4.0
* Initial stable release

View File

@ -15,21 +15,25 @@ Some of the more interesting features:
## Recent changes
Improvements are being made almost daily, but bigger changes are described here (until we get to
a more formal release process):
* Reworked SSH keys and support for running CI builds [Aug 11 2016](CHANGES.md#aug-11-2016)
* Create command was split into create and update [Jul 21 2016](CHANGES.md#jul-21-2016)
Change history is available in [HISTORY.md](HISTORY.md)
## Installation
We recommend using a release from the Release tab above.
## Installation from source
Build the code (make sure you have set GOPATH):
```
go get -d k8s.io/kops
git checkout release
cd ${GOPATH}/src/k8s.io/kops/
make
```
* The `release` branch is where releases are taken from. This is the stable code branch.
* The `master` branch _should_ also be functional, but is where active development happens, so may be less stable.
(Note that the code uses the relatively new Go vendoring, so building requires Go 1.6 or later,
or you must export GO15VENDOREXPERIMENT=1 when building with Go 1.5. The makefile sets
GO15VENDOREXPERIMENT for you. Go code generation does not honor the env var in 1.5, so for development

13
docs/releases.md Normal file
View File

@ -0,0 +1,13 @@
## Branch strategy
We develop on the master branch. The master branch is expected to build and generally to work,
but has not necessarily undergone the more complete validation that a release would. The `release`
branch is expected to always be stable.
We tag releases as needed from the `release` branch and upload them to github.
We occasionally batch merge from the master branch to the `release` branch. We don't maintain
multiple release branches as we expect most people to upgrade kops to the latest version. We also
don't (yet) do lots of cherry-picking for that reason.
The intention is that this allows for development velocity, while also allowing for stable releases.

View File

@ -23,7 +23,7 @@ import (
)
const (
NodeUpVersion = "1.4.0"
NodeUpVersion = "1.4.1"
)
const MaxAttemptsWithNoProgress = 3