This documentation covers the proposed release process that will improve
support for versioning builds from tarball.
There's also a diagram to explain how versioning works in face of other
commits being merged in parallel and the quirks of intermediate versions
close to the release window.
Addresses Issue #1226.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
We took a hard look at 1.0 and what things ae really REQUIRED to get to a
stable release that is "useful". This required moving some things we thought
were really important but not CRITICAL down the list.
For now they are stricken from this doc, but I expect this doc to start
growing a "post 1.0" list soon.
Things stricken and why:
Using the host network: This is primarily a performance optimization, but it
causes potential problems with other uses of HostPorts. We'd rather focus on
fixing perf problems than dodging them. We can revisit later if there is a
strong case for it.
Representation of Ports in the Manifest structure: We discussed and decided
that, since HostPort semantics have changed, this matters less than before.
Scenarios where IP-per-pod is hard or impossible: We're still game to help
people figure out how to make it work, but we don't see a case for making k8s
1.0 work in a fundamentally different mode. Too much churn and risk. We can
revisit later, if needed.
Auto-scaling controller: We really want this, but it's not critical to making
k8s "useful".
Pluggable authentication: Overlaps with the other identity topic. Having one
topic seems clearer.
Pod spreading: We still want this, but it's not critical for 1.0.
Container status snippets: We still want this, but it's not critical for 1.0.
Docker-daemon-kills-all-children-on-exit problem: This is still a big problem,
but we're not going to gate our 1.0 on something we don't control. This has
to be documented as a shortcoming in general.
Interconnection of services: expand / decompose the service pattern: overlaps
with the other services topic.
Recipes for settings where networking is not like GCE: This is happening in
the form of cloudprovider modules, but is not going to gate 1.0.
Instead of using `godep path`, we can simply set the GOPATH directly to
point to the Godeps/_workspace. We can still use `godep` to manage the
dependencies on the Godeps/ tree, but we don't need to have it available
for straight builds from git.
v2: Rebased and moved to inside kube::setup_go_environment() function.
Tested:
- Built it without godep in $PATH:
$ hack/build-go.sh
- Ran unit tests without godep in $PATH:
$ hack/test-go.sh
- Retested after rebase.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
While the linux dependency is obvious with a moment's thought, some
users (especially on *nix) might plow ahead before realizing their
system isn't supported. This adds a requirements section and points
users in the direction of guides more likely to work for them.