release: Remove the release process docs
These docs weren't useful for outside contributors and used internal terminology
and tooling. Once we migrate to a separate system based on GKE, we'll reinstate
this, but for now, it just creates confusion.
Change-Id: Ic5b015808debce3e5a0d9959c87f109e6917a3ef
diff --git a/ReleaseProcess.md b/ReleaseProcess.md
deleted file mode 100644
index 6580e82..0000000
--- a/ReleaseProcess.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Release Process
-
-1. Update all or some of the package version numbers
- - All of the package changelogs need to have the proper release listed in the
- changelog after the package number.
-2. Create the release branch in all projects
-3. Create the release branch in continuous-build
- - Add branch=release-$RELEASE for all projects in .gitmodules
- - git submodule update --remote --init
- - git add -A; git commit
- - git push origin HEAD:refs/heads/release-$RELEASE
-4. All package repositories we have updated need to have git tags
- - Format of the tag is the same as the package version in the
- debian/changelog file.
- - git tag $VERSION aiy/release-$RELEASE
- - If the package has separate sources in another repo, you need to tag the
- same way in the source repo.
- - git push --tags aiy
-5. Make a new release candidate for the appropriate release
- - If no proposals exist for the release, create a new Rollup proposal and
- approve it.
-6. Tag the latest rapture with the $RELEASE tag.
- - rapture --universe cloud-apt settag mendel-core-unstable spacepark-eng.$RELEASE:true
-7. Run the kokoro job for $RELEASE.
-
-Cherry picks:
-1. Commit to master
-2. Cherry pick to next branch
-3. All packages we have updated need to have tags
-4. Checkout $current-release in continuous
-5. `git submodule update --remote --init`
-6. Check status, update git submodules, commit
-7. Run the rapid release job on for $current-release
- - Looks at the next branch looking for the latest versions and updates that way
-8. Tag the latest rapture with the next tag.
