Remove out-of-date information about releasing

1 files changed, 0 insertions, 74 deletions

diff --git a/releasing.md b/releasing.md
index 9a73405f..6ff8e862 100644
--- a/releasing.md
+++ b/releasing.md
@@ -249,80 +249,6 @@ can, for instance, tell it to override `gitVersion` and set it to
 `v0.4-13-g4567bcdef6789-dirty` and set `gitCommit` to `4567bcdef6789...` which
 is the complete SHA1 of the (dirty) tree used at build time.
 
-## Handling Official Versions
-
-Handling official versions from git is easy, as long as there is an annotated
-git tag pointing to a specific version then `git describe` will return that tag
-exactly which will match the idea of an official version (e.g. `v0.5`).
-
-Handling it on tarballs is a bit harder since the exact version string must be
-present in `pkg/version/base.go` for it to get embedded into the binaries. But
-simply creating a commit with `v0.5` on its own would mean that the commits
-coming after it would also get the `v0.5` version when built from tarball or `go
-get` while in fact they do not match `v0.5` (the one that was tagged) exactly.
-
-To handle that case, creating a new release should involve creating two adjacent
-commits where the first of them will set the version to `v0.5` and the second
-will set it to `v0.5-dev`. In that case, even in the presence of merges, there
-will be a single commit where the exact `v0.5` version will be used and all
-others around it will either have `v0.4-dev` or `v0.5-dev`.
-
-The diagram below illustrates it.
-
-![Diagram of git commits involved in the release](releasing.png)
-
-After working on `v0.4-dev` and merging PR 99 we decide it is time to release
-`v0.5`. So we start a new branch, create one commit to update
-`pkg/version/base.go` to include `gitVersion = "v0.5"` and `git commit` it.
-
-We test it and make sure everything is working as expected.
-
-Before sending a PR for it, we create a second commit on that same branch,
-updating `pkg/version/base.go` to include `gitVersion = "v0.5-dev"`. That will
-ensure that further builds (from tarball or `go install`) on that tree will
-always include the `-dev` prefix and will not have a `v0.5` version (since they
-do not match the official `v0.5` exactly.)
-
-We then send PR 100 with both commits in it.
-
-Once the PR is accepted, we can use `git tag -a` to create an annotated tag
-*pointing to the one commit* that has `v0.5` in `pkg/version/base.go` and push
-it to GitHub. (Unfortunately GitHub tags/releases are not annotated tags, so
-this needs to be done from a git client and pushed to GitHub using SSH or
-HTTPS.)
-
-## Parallel Commits
-
-While we are working on releasing `v0.5`, other development takes place and
-other PRs get merged. For instance, in the example above, PRs 101 and 102 get
-merged to the master branch before the versioning PR gets merged.
-
-This is not a problem, it is only slightly inaccurate that checking out the tree
-at commit `012abc` or commit `345cde` or at the commit of the merges of PR 101
-or 102 will yield a version of `v0.4-dev` *but* those commits are not present in
-`v0.5`.
-
-In that sense, there is a small window in which commits will get a
-`v0.4-dev` or `v0.4-N-gXXX` label and while they're indeed later than `v0.4`
-but they are not really before `v0.5` in that `v0.5` does not contain those
-commits.
-
-Unfortunately, there is not much we can do about it. On the other hand, other
-projects seem to live with that and it does not really become a large problem.
-
-As an example, Docker commit a327d9b91edf has a `v1.1.1-N-gXXX` label but it is
-not present in Docker `v1.2.0`:
-
-```console
-$ git describe a327d9b91edf
-v1.1.1-822-ga327d9b91edf
-
-$ git log --oneline v1.2.0..a327d9b91edf
-a327d9b91edf Fix data space reporting from Kb/Mb to KB/MB
-
-(Non-empty output here means the commit is not present on v1.2.0.)
-```
-
 ## Release Notes
 
 No official release should be made final without properly matching release notes.