Specify that the tag should be annotated.

doc/release/monthly.md

@@ -61,9 +61,9 @@ After making the release branch new commits are cherry-picked from master. When
 * 1-7th: official merge window (see contributing guide)
 * 8-14th: work on bugfixes, sponsored features and GitLab EE
 * 15th: code freeze (stop merging into master except essential bugfixes)
-* 18th: release candidate 1 (VERSION x.x.0.rc1, tag and tweet about x.x.0.rc1, release on GitLab Cloud)
+* 18th: release candidate 1 (VERSION x.x.0.rc1, annotated tag and tweet about x.x.0.rc1, release on GitLab Cloud)
 * 20st: optional release candidate 2 (x.x.0.rc2, only if rc1 had problems)
-* 22nd: release (VERSION x.x.0, create x-x-stable branch, tag, blog and tweet)
+* 22nd: release (VERSION x.x.0, create x-x-stable branch, annotated tag tag, blog and tweet)
 * 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems)
 * 24-end of month: release GitLab EE and GitLab CI
 

doc/release/security.md

@@ -18,7 +18,7 @@ Please report suspected security vulnerabilities in private to support@gitlab.co
 1. Create feature branches for the blog post on GitLab.com and link them from the code branch
 1. Merge the code feature branch into master
 1. Cherry-pick the code into the latest stable branch
-1. Create a git tag vX.X.X for CE and another patch release for EE
+1. Create an annotated tag vX.X.X for CE and another patch release for EE
 1. Push the code and the tags to all the CE and EE repositories
 1. Apply the patch to GitLab Cloud and the private GitLab development server
 1. Merge and publish the blog posts