q3k
/
docker-cli-openbsd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Clean up explanation of doc branches. 

Signed-off-by: Peter Salvatore <peter@psftw.com>
master
Peter Salvatore 2015-02-12 16:50:39 -05:00 committed by Tibor Vass
parent 8c6610787a
commit e2ac0fc917
1 changed files with 17 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
docs/README.md
View File

@ -3,11 +3,10 @@
The source for Docker documentation is here under `sources/` and uses extended The source for Docker documentation is here under `sources/` and uses extended
Markdown, as implemented by [MkDocs](http://mkdocs.org). Markdown, as implemented by [MkDocs](http://mkdocs.org).
The HTML files are built and hosted on `https://docs.docker.com`, and update The HTML files are built and hosted on
automatically after each change to the master or release branch of [Docker on [http://docs.docker.com](http://docs.docker.com), and update automatically
GitHub](https://github.com/docker/docker) thanks to post-commit hooks. The after each change to the `docs` branch of [Docker on
`docs` branch maps to the "latest" documentation and the `master` (unreleased GitHub](https://github.com/docker/docker) thanks to post-commit hooks.
development) branch maps to the "master" documentation.
## Contributing ## Contributing
@ -61,25 +60,21 @@ work!](../CONTRIBUTING.md#sign-your-work)
## Branches ## Branches
| Branch | Description | URL (published via commit-hook) |
|----------|--------------------------------|------------------------------------------------------------------------------|
| `docs` | Official release documentation | [http://docs.docker.com](http://docs.docker.com) |
| `master` | Unreleased development work | [http://docs.master.dockerproject.com](http://docs.master.dockerproject.com) |
**There are two branches related to editing docs**: `master` and `docs`. You **There are two branches related to editing docs**: `master` and `docs`. You
should always edit the documentation on a local branch of the `master` should always edit the documentation on a local branch of the `master` branch,
branch, and send a PR against `master`. and send a PR against `master`. That way your fixes will automatically get
included in later releases, and docs maintainers can easily cherry-pick your
changes into the `docs` release branch. In the rare case where your change is
not forward-compatible, you may need to base your changes on the `docs` branch.
That way your fixes will automatically get included in later releases, and docs Also, since there is a separate `docs` branch, we can keep
maintainers can easily cherry-pick your changes into the `docs` release branch. [http://docs.docker.com](http://docs.docker.com) up to date with any bugs found
In the rare case where your change is not forward-compatible, you may need to between Docker code releases.
base your changes on the `docs` branch.
Also, now that we have a `docs` branch, we can keep the
[http://docs.docker.com](http://docs.docker.com) docs up to date with any bugs
found between Docker code releases.
> **Warning**: When *reading* the docs, the
> [http://docs-stage.docker.com](http://docs-stage.docker.com) documentation may
> include features not yet part of any official Docker release. The `beta-docs`
> site should be used only for understanding bleeding-edge development and
> `docs.docker.com` (which points to the `docs` branch`) should be used for the
> latest official release.
## Publishing Documentation ## Publishing Documentation