Release post - GitLab 11.4

Review Apps: https://release-11-4.about.gitlab.com/2018/10/22/gitlab-11-4-released/

Release post:

• Intro: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-11-4/source/posts/2018-10-22-gitlab-11-4-released.html.md
• Items: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-11-4/data/release_posts/2018_10_22_gitlab_11_4_released.yml
• Images: https://gitlab.com/gitlab-com/www-gitlab-com/tree/release-11-4/source/images/11_4

Related files:

• Features YAML link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-11-4/data/features.yml
• Home page banner: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-11-4/source/includes/hello-bar.html.haml
• MVPs: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-11-4/data/mvps.yml

Handbook references:

• Blog handbook: https://about.gitlab.com/handbook/marketing/blog/
• Release post handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/
• Markdown guide: https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/

People:

• Release Post Managers: https://about.gitlab.com/handbook/marketing/blog/release-posts/managers/
• Release Managers: https://about.gitlab.com/release-managers/

Release post manager	Tech writer	Copyedit	Messaging Lead	Social
@jramsay	@eread	xx	@johnjeremiah	xx

General contributions

Due date: 2018-10-12 (6th working day before the 22nd)

All contributions added by team members, collaborators, and Product Managers (PMs).

Author's checklist

Due date: 2018-10-12 (6th working day before the 22nd) - @jramsay

The PM leading the post is responsible for adding and checking the following items:

• Label MR: ~"blog post" release release post ~P1
• Assign the MR to yourself
• Add milestone
• Update the links and due dates in this MR description
• Make sure the blog post initial files, as well as this MR template contain the latest templates
• Add authorship (author's data)
• Ask the Marketing reviewer to add the introduction
• Add MVP (feature block)
• Add MVP to data/mvps.yml
• Add cover image (image_title) (scaled and compressed)
• Add social sharing image (twitter_image) (scaled and compressed)
• Make sure all feature descriptions are positive and cheerful
• Make sure all features listed in the direction page are included in the post
• Mention the release managers to remind them to add the upgrade barometer section
• Mention the team leads to remind them to add the performance improvements: Yorick, Douwe, Sean, Remy, Stan, Kamil, Tim Z., Clement, Andre
• Ping @atflowers and @aoetama to add the Release Radar webcast link
• Make sure Upgrade barometer is in
• Check which one is the top feature (with Job and William)
• Check if deprecations are included
• Alert people one working day before each due date (post a comment to #release-post Slack channel)
• Remove remaining template sections
• Make sure all images (png, jpg, and gifs) are smaller than 300 KB each
• Run the release post through an automated spell and grammar check
• Perform the content review

Recurring blocks

Due date: 2018-10-12 (6th working day before the 22nd)

The following sections are always present, and managed by the PM or Eng lead owning the related area:

• Add GitLab Runner improvements: Fabio
• Add Omnibus improvements: Joshua
• Add Mattermost update to the Omnibus improvements section: Victor
• Add Performance improvements: Douwe, Sean, Kamil, Yorick, Tim

Feature blocks

Due date: 2018-10-12 (6th working day before the 22nd)

The Product Managers are responsible for adding their feature blocks to the release post by the due date for general contributions. PMs are also responsible for adding any notable Community Contributions.

PMs: please check your box only when all your features and deprecations were added with completion (documentation links, images, etc). Pls don't check if there are still things missing.

• Andreas (@akaemmerle)
• Daniel (@danielgruesso)
• Fabio (@bikebilly)
• James (@jramsay)
• Jason (@jlenny)
• Jeremy (@jeremy_)
• Joshua (@joshlambert)
• Victor (@victorwu)

Tip: make your own checklist:

• Primary features
• Improvements (secondary features)
• Deprecations
• Documentation updated
• Documentation links added to the post
• Community contributions
• Illustrations added to the post (compressed)
• Update features.yml (with accompanying screenshots)

Review

Ideally, complete the review until the 4th working day before the 22nd, so that the 3rd and the 2nd working day before the release could be left for fixes and small improvements.

Content review

Due date: 2018-10-15 (5th working day before the 22nd)

Performed by the author of the post: @jramsay

• Label MR: ~"blog post" release review-in-progress
• Check all comments in the thread (make sure no contribution was left behind)
• Check Features' names
• Check Features' availability (Core, Starter, Premium, Ultimate badges)
• Check Documentation links (all feature blocks contain documentation_link)
• Make sure documentation_link links to feature webpages when available
• Update home page bannersource/includes/hello-bar.html.haml
• Features were added to data/features.yml (with accompanying screenshots)
• Check all images size < 300KB (compress them all with TinyPNG or similar tool)
• Pull master, resolve any conflicts
• Make sure all discussions in the thread are resolved
• Mention Mark Pundsack to remind him to review
• Assign the MR to the next reviewer (structural check)
• Lock features.yml with File Locking on the 21st

Structural check

Due date: 2018-10-17 (3rd working day before the 22nd)

Performed by technical writers: @eread

• 1. Structural check
• Add the label review-structure
• Check frontmatter (entries, syntax)
• Check image_title and twitter_image
• Check image shadow applied correctly: {image_noshadow: true} when an image already has shadow
• Videos/iframes wrapped in <figure> tags (responsiveness)
• Wrap text
• Check headers in sentence case
• Check feature and product names in capital case
• Check if images are harmonic/consistent
• Add/check cover img reference (at the end of the post)
• Columns (content balance between the columns)
• Meaningful links (SEO)
• Badges consistency (applied to all headings)
• Double check documentation updates
• Check documentation links (point to /ee/, not to /ce/)
• Check about.gitlab.com links: relative URLs
• Check the anchor links in the intro
• Remove any remaining instructions
• Remove HTML comments
• Run deadlink checker
• Pull master
• Update release template with any changes (if necessary)
• Post a comment in the #general channel linking to the review app + MR reminding the team to take a look at the RP and report any problems in the #release-post channel. (Do NOT ping @all or @channel)
• Remove the label review-structure
• Assign the MR to the next reviewer (copyedit)

Further reviews

Due date: 2018-10-18 (2nd working day before the 22nd)

• Copyedit (content team): @erica
  • Title
  • Description
  • Intro
  • Grammar, spelling, clearness (body)
  • Homepage Blurb
  • Tweet social sharing text (for Twitter, FB, and LinkedIn)
  • Assign the MR to the next reviewer (marketing)
• Marketing review (PMMs - messaging lead): @johnjeremiah
  • Write the introduction (by the 6th day before the 22nd)
  • Check/copyedit feature blocks
  • Check/copyedit features.yml
  • Check/copyedit homepage blurb
  • Check/copyedit social sharing text
  • Mention Job for final check
  • Remove the label review-in-progress
  • Assign the MR back to the author

Merge it

The author of the post is responsible for merging the MR and following up with possible adjustments/fixes.

Last check before merging

• Read the important notes below
• Mention @matteeyah to remind him to send the swag pack to the MVP
• Check if all the anchor links in the intro are working
• Check if there are no broken links
• Pull master and fix any conflicts
• Check if there isn't any alert on Slack's #release-post and #general channels
• Check if there isn't any alert on this MR thread
• Check if the tweet copy is ready and someone is ready to share on social media
• Ask the release managers to ping you when the packs are publicly available (and GitLab.com is up and running on the release version)
• Unlock features.yml just before merging
• Merge the MR
• Wait for the pipeline
• Check the look on social media with Twitter Card Validator and Facebook Debugger
• Share on social media

Important notes

• The post is to be merged on the 22nd at 15:00 UTC and as soon as GitLab.com is up and running on the new release version, and all packages are publicly available. Not before.
• The usual release time is 15:00 UTC but it varies according to the deployment. If something comes up and delays the release, the release post will be delayed with the release.
• Coordinate the timing with the release managers. Ask them to keep you in the loop.
• After merging, wait a few minutes to see if no one spot an error (usually posted in #general), then share on Twitter, Facebook, and LinkedIn, or make sure someone (Emily vH, JJ, Marcia) does.
• Keep an eye on Slack and in the blog post comments for a few hours to make sure no one found anything that should be fixed

data/release_posts/2018_10_22_gitlab_11_4_released.yml

@@ -47,15 +47,15 @@ features:
         have conversations linked to specific lines of code in a diff, and can even
         resolve them. However, the process can get unwieldy in merge requests with
         large diffs. Often, a reviewer may need to leave upwards of 10 or more comments
-        in a single sitting. And the 9th or 10th comment may actually  render earlier
-        comments unnecessary. The end result is that the the merge request author
+        in a single sitting. And the 9th or 10th comment may actually render earlier
+        comments unnecessary. The end result is that the merge request author
         gets a slew of notifications and has to sort them out one by one.
         With this release, we are introducing batch comments for code review in
         GitLab merge requests. This will allow a reviewer to draft as many comments
         as they wish, make sure they are all consistent, and then submit them all
         as a single action. Since the drafts are saved to GitLab, a reviewer can
-        even spread their work across many sittings, say starting a review on their
+        even spread their work over many sessions, say starting a review on their
         desktop at work during the day, and then wrapping it up at home on their
         tablet device later in the evening. Once the draft comments are submitted,
         they appear as normal individual comments. This allows individual team members
@@ -146,9 +146,9 @@ features:
         kinds of assets or builds, ensuring only the appropriate steps are
         executed for the kinds of changes that were committed.
-    - name: "Add feature flags for applications (ALPHA)"
+    - name: "Add feature flags for applications (ALPHA) **[PREMIUM]**"
       available_in: [premium, ultimate] # required
-      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/feature-flags' # required
+      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/feature_flags.html' # required
       image_url: '/images/11_4/feature-flags.png' # required
       reporter: jlenny # required
       team: release # required
@@ -165,7 +165,7 @@ features:
         we want you to be aware that the implementation could change in subsequent
         releases.
-    - name: "Add timed incremental rollouts to AutoDevOps"
+    - name: "Add timed incremental rollouts to AutoDevOps **[PREMIUM]**"
       available_in: [premium, ultimate] # required
       documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#timed-incremental-rollout-to-production' # required
       image_url: '/images/11_4/timed-incremental-rollouts.png' # required
@@ -174,21 +174,7 @@ features:
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/7545' # required
       description: | # supports markdown
         You've had the ability within AutoDevOps to setup incremental
-        rollouts for a while now, and with this release we are adding
-        an option to also set up _timed_ incremental rollouts where
-        the rollout will automatically continue on a timed cadence
-        unless there is some error.
-
-    - name: "Make GitLab Pages support access control"
-      available_in: [core, starter, premium, ultimate] # required
-      documentation_link: 'https://docs.gitlab.com/ee/user/project/pages/#getting-started' # required
-      image_url: '/images/11_4/pages-access-control.png' # required
-      reporter: jlenny # required
-      team: release # required
-      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/33422' # required
-      description: | # supports markdown
-        You've had the ability within AutoDevOps to setup incremental
-        rollouts for a while now, and with this release we are adding
+        rollouts for a while now, and with this release, we are adding
         an option to also set up _timed_ incremental rollouts where
         the rollout will automatically continue on a timed cadence
         unless there is some error.
@@ -203,7 +189,7 @@ features:
       description: | # supports markdown
         Security is paramount when setting up your infrastructure for the first time or connecting to
         existing one. Role-based access control (RBAC) was made generally available as part of Kubernetes'
-        1.8 release, providing more granular controls to regulate access to kubernetes resources.
+        1.8 release, providing more granular controls to regulate access to Kubernetes resources.
         Our Kubernetes integration will now offer the capability to either create an RBAC-enabled
         cluster on GKE or to connect with an existing cluster that is RBAC-enabled, providing increased
@@ -216,10 +202,10 @@ features:
       team: configure
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44597' # required
       description: | # supports markdown
-        Auto DevOps now supports interacting with and deploying applications to RBAC-enabled kubernetes clusters.
+        Auto DevOps now supports interacting with and deploying applications to RBAC-enabled Kubernetes clusters.
         Role-based access control (RBAC) is an important tool that allows operators to ensure the reliability,
-        security, and efficiency of their kubernetes cluster. Using Auto DevOps in conjunction with an RBAC-enabled
+        security, and efficiency of their Kubernetes cluster. Using Auto DevOps in conjunction with an RBAC-enabled
         cluster ensures your applications take advantage of the increased infrastructure security.
     - name: "Support PostgreSQL DB migration and initialization for Auto DevOps"
@@ -247,7 +233,7 @@ features:
       team: plan
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/50835'
       description: |
-        Labels in GitLab are very powerful, since they can be applied to issues,
+        Labels in GitLab are very powerful since they can be applied to issues,
         merge requests, and epics. As you use more labels, it can be difficult to
         maintain them.
@@ -351,7 +337,7 @@ features:
         from a small number to effectively unlimited, any number greater than zero.
         With this release, we've brought this flexibility to the issues API as well,
-        allowing users to set this field with the new expanded number range with
+        allowing users to set this field with the newly expanded number range with
         the API.
     - name: "Lock discussion quick action"
@@ -390,6 +376,7 @@ features:
     - name: "Improve Admin Area settings UI"
       available_in: [core, starter, premium, ultimate]
+      gitlab_com: false
       documentation_link: 'https://docs.gitlab.com/ee/#amazing' # webpage or documentation - required
       image_url: '/images/X_Y/feature-a.png' # optional - recommended
       reporter: akaemmerle
@@ -437,7 +424,6 @@ features:
     - name: "Redesign settings pages: Group settings"
       available_in: [core, starter, premium, ultimate] # required
-      gitlab_com: false # required if the feature is NOT available in GitLab.com. Else, delete this line.
       documentation_link: 'https://docs.gitlab.com/ee/#amazing' # webpage or documentation - required
       image_url: '/images/X_Y/feature-a.png' # optional - recommended
       reporter: akaemmerle
@@ -468,7 +454,7 @@ features:
         Thank you for this contribution, [Johann Hubert Sonntagbauer](https://gitlab.com/johann.sonntagbauer)
-    - name: "Download two factor authentication codes as files"
+    - name: "Download two-factor authentication codes as files"
       available_in: [core, starter, premium, ultimate]
       documentation_link: 'https://docs.gitlab.com/ee/#amazing' # webpage or documentation - required
       image_url: '/images/X_Y/feature-a.png' # optional - recommended
@@ -487,6 +473,7 @@ features:
     - name: "Filter Admin Runners view by Runner Type and State"
       available_in: [core, starter, premium, ultimate] # required
+      gitlab_com: false
       documentation_link: 'https://docs.gitlab.com/ee/ci/runners/' # required
       image_url: '/images/11_4/runner-admin-filter.png' # required
       reporter: jlenny # required
@@ -499,6 +486,7 @@ features:
     - name: "Add support for interactive web terminal to Docker executor"
       available_in: [core, starter, premium, ultimate] # required
+      gitlab_com: false
       documentation_link: 'https://docs.gitlab.com/ee/ci/interactive_web_terminal/' # required
       reporter: jlenny # required
       team: verify # required
@@ -518,7 +506,7 @@ features:
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/51352' # required
       description: | # supports markdown
         It is now possible to set a job to start after a delay timer
-        via the .gitlab-ci.yml. The timer starts ticking when the job
+        via the `.gitlab-ci.yml`. The timer starts ticking when the job
         would have otherwise started, giving you control to implement
         tasks that need to wait for a period of time to occur - for
         example, when implementing timed incremental rollouts, or any
@@ -535,7 +523,7 @@ features:
         in order to determine which jobs to skip. This will result in faster Auto DevOps pipeline when
         certain features are not in use.
-        This will not only save you time but will also result in cleaner view of Auto DevOps pipeline,
+        This will not only save you time but will also result in a cleaner view of Auto DevOps pipeline,
         showing you only the relevant jobs for your project.
     - name: "Manually add entries in the License Management settings"
@@ -568,13 +556,13 @@ features:
         [wire protocol](https://www.kernel.org/pub/software/scm/git/docs/technical/pack-protocol.html)
         which defines how clones, fetches and pushes are communicated between
         the client (your computer) and the server (GitLab). The new wire
-        protocol improves performance of fetch commands and enables future
+        protocol improves the performance of fetch commands and enables future
         protocol improvements.
         Previously, all responses to fetch commands included a list of all
-        all references in the repository. For example, fetching updates for a
+        references in the repository. For example, fetching updates for a
         single branch (e.g. `git fetch origin master`) would also retrieve a
-        complete list of all references. In the case of large projects this
+        complete list of all references. In the case of large projects, this
         could be over 100,000 refs and 10s of megabytes of data. Try it
         yourself by running:
@@ -590,24 +578,6 @@ features:
         globally run `git config --global protocol.version=2`. Git protocol v2
         over SSH is not yet enabled on GitLab.com and must be enabled manually
-
-    - name: "Lorem ipsum"
-      available_in: [premium, ultimate] # required
-      gitlab_com: false # required if the feature is NOT available in GitLab.com. Else, delete this line.
-      documentation_link: 'https://docs.gitlab.com/ee/#amazing' # webpage or documentation - required
-      image_url: '/images/X_Y/feature-a.png' # optional - recommended
-      video: 'https://www.youtube.com/embed/enMumwvLAug' # example - optional - overrides image_url
-      reporter: pm1 # required
-      team: teamname # required
-      issue_url: ''
-      description: | # supports markdown
-        Lorem ipsum [dolor sit amet](#link), consectetur adipisicing elit.
-        Perferendis nisi vitae quod ipsum saepe cumque quia `veritatis`.
-
-        Lorem ipsum dolor sit amet, consectetur adipisicing elit.
-        Voluptate eveniet, adipisci earum sed harum nostrum
-        itaque beatae, repellat sunt unde.
-
     - name: "Geo improvements"
       available_in: [premium, ultimate]
       gitlab_com: false
@@ -640,7 +610,7 @@ features:
       reporter: pm1 # required
       team: teamname # required
       description: | # supports markdown
-        Some of the more noteworthy performance improvements in GitLab 11.2 include:
+        Some of the more noteworthy performance improvements in GitLab 11.4 include:
         * [Rendering Markdown with many label references is faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/48221)
         * [Issue discussions with many cross-project commit references are faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/43094)
@@ -697,15 +667,10 @@ barometer:
 # DEPRECATIONS (optional)
 # include as many deprecation blocks as necessary
 deprecations:
-  - feature_name: "Lorem ipsum dolor"
-    due: May 22nd, 2017. # example
-    reporter: pm1 # required
-    description: |  # example (supports markdown)
-      Lorem ipsum dolor sit amet, consectetur adipisicing elit.
-      Veritatis, quisquam.
-  - feature_name: "Lorem ipsum dolor"
-    due: May 22nd, 2017.
-    reporter: pm1 # required
-    description: |  # example (supports markdown)
-      Lorem ipsum dolor sit amet, consectetur adipisicing elit.
-      Veritatis, quisquam.
+  - feature_name: "Support for Docker Versions in GitLab Runner"
+    due: October 22, 2018
+    reporter: jlenny
+    description: |
+      With GitLab 11.4 (October 22, 2018), support for Docker versions before 1.12 (API version 1.24) have been be deprecated in line with
+      Docker's latest [version recommendation guidance](https://docs.docker.com/develop/sdk/#api-version-matrix). Beyond
+      the 11.4 release these older versions are no longer be officially supported and could stop working at any time.