TL;DR

• Always use the correct OpenShift documentation (3.4 is currently the latest released version) and you can also refer to Kubernetes documentation but Kubernetes documentation is not versioned,
• oc cli tool, is mostly a wrapper around kubectl, so you can refer to better documented kubectl documentation for managing Kubernetes resources,
• Always use the same oc cli version with your OpenShift cluster,or prepare to deal with broken cluster components like registry, router, etc.,
• Don’t use the documentation pages google find’s for you, google nearly always redirects you to old versions’ documentation, always check URL google takes you to, if you familiarize yourself with the different documentation URLs :(, you can do the trick yourself: ..shift.com/container-platform/3.4/…,
• Don't expect all Kubernetes features in corresponding OpenShift version, they selectively enable alpha features,
• Don't expect to find a list about how/where OpenShift differentiates from Kubernetes (y u do this RedHat !?!?!)

Some background and how we came here

So, as I can follow it, here is a summary about OpenShift's history's impact on their documentation and open source branches. This could also tell about the current state of their documentation.

Pre-Kubernetes era (OpenShift v2)

OpenShift started with their in-house PaaS implementation:

• This was OpenShift v2, so don’t consider any v2 documentation for Kubernetes related implementation, google searches could end you up on documentation for this old different product,
• “Origin” name was also used as project name for v2, don't assume it's OpenShift v3 only,
• If you see “rhc” tool, “gear”, “cartridge” or “broker” terms in any documentation it's likely OpenShift v2, not something you want,

Re-implementation with Kubernetes (OpenShift v3)

After some stage, OpenShift decided to switch to Kubernetes, this is when they start calling it OpenShift v3.

When the switch to Kubernetes happened, they had to bump the major version of the product, and start using 3 as major version, therefore we have OpenShift v3. But while doing the transition, they decided to keep the major number in sync with Kubernetes for the open source version(Origin).

This created diversion between major versions and here is a mapping between OpenSource and Enterprise versions:

• OpenShift Enterprise 3.1 == Origin 1.1 (based on Kubernetes 1.1, minor numbers doesn’t match)
• OpenShift Enterprise 3.2 == Origin 1.2 (based on Kubernetes 1.2, minor numbers doesn’t match)

Enterprise (old) == Container Platform (new)

Recently they decided to re-brand the “Enterprise” version as “Container Platform”, so we ended up with this new mapping, they also updated the doc URLs accordingly:

• OpenShift Container Platform 3.3 == Origin 1.3 (based on Kubernetes 1.3, minor numbers doesn’t match)
• OpenShift Container Platform 3.4 == Origin 1.4 (based on Kubernetes 1.4, minor numbers doesn’t match)

Open source version (Origin) documentation is not versioned, use enterprise documentation

Open source version’s documentation is never versioned as I know, and has always been pointing to the head of development tree hence always “latest” in the URL. OpenShift Origin Latest, be careful about this one because this points to latest branch in their repo (currently unreleased 1.5). Also don't expect it to be fully up-to-date for the upcoming release.

So for open source versions (Origin 1.2, 1.3, 1.4) since you don't have versioned documentation, you can use the corresponding Enterprise version's documentation. Some feature's may differ between enterprise and open source versions, mostly on installation steps and the load-balancer for cluster masters, but the enterprise version's documentation can still help a lot.

Similar to documentation when referring to source code and ansible scripts to maintain cluster always stick to the branches for your version:

• https://github.com/openshift/origin/tree/release-1.4, not https://github.com/openshift/origin
• https://github.com/openshift/openshift-ansible/tree/release-1.4 (if you followed advanced installation)

List of documentation URLs for different releases

The open source and enterprise documentation “domains” are as well different, it's important to get familiar with the URL templates they use if you want to start with open source version:

• https://docs.openshift.org/latest/welcome/index.html (points latest in development)
• https://docs.openshift.com/container-platform/3.4/welcome/index.html (current last release)
• https://docs.openshift.com/container-platform/3.3/welcome/index.html
• https://docs.openshift.com/enterprise/3.2/welcome/index.html
• https://docs.openshift.com/enterprise/3.1/welcome/index.html
• https://developers.openshift.com/ (OpenShift v2, DON'T USE ANYTHING UNDER THIS DOMAIN)

OpenShift v.s. Kubernetes, cli and docs

• OpenShift’s oc tool is based on the kubectl codebase (I guess but didn't check), more like a wrapper around the same source code with OpenShift awareness and some extended capabilities,
• OpenShift master nodes come with kubectlsoft-linked to oc, you can have an idea about compatibility,
• OpenShift has an additional cli tool, called “oadm”. This has been integrated into “oc” tool as “oc adm” sub-command, so you can use oc adm in your laptop instead of trying to use oadm in masters, but to be able to use “oc adm” you should be using it with a user with “cluster-admin” role,
• All “oc”, “oadm”, “kubectl” commands store the credentials and context in “~/.kube” directory, and commands like “{kubectl,oc} config” mutates that file to set/keep the context ,
  
• “kubectl” documentation can be found here and you an refer to it for most “oc” sub-commands, this kubectl cheatsheet helps a lot with getting familiar with “kubectl”.

Use correct “oc” version

If you wan't to manage the cluster components from your laptop, you “have to” use the same oc client with your OpenShift cluster version. So this is must: “oc.client.version == openshift.cluster.version”, you can check both versions with oc version command.

E.g. If you use a more recent version of “oc” than your cluster, and want to install a new router, it'll likely fail. This is mostly because the “oc” cli has the logic for how to deploy a router, “oc” tool creates some Kubernetes resources in the cluster but if the cli tool does not match the cluster version, it's likely that the resources generated by newer cli version won't match the configuration of a recent OpenShift version's requirements.

If you used oc cluster up it will up a cluster with the same version with your “oc” client, so if you have old “oc” version, you'll likely get an old OpenShift cluster.