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

@@ -80,14 +80,13 @@ features:
     - name: "New user profile page overview"
       available_in: [core, starter, premium, ultimate]
-      gitlab_com: false
       documentation_link: 'https://docs.gitlab.com/ee/user/profile/#user-profile'
       image_url: '/images/11_4/user-profile-redesign.png'
       reporter: akaemmerle
       team: manage
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/49801'
       description: |
-        Now matter how engaged you are on GitLab, your activity is a relevant
+        No matter how engaged you are on GitLab, your activity is a relevant
         source of information and engagement indicator, displayed right at your
         personal profile page. Your personal profile should give a simple insight
         into what you are interested in and working on.
@@ -106,8 +105,8 @@ features:
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/49075'
       description: |
         With [GitLab 11.2](/2018/08/22/gitlab-11-2-released/#personal-status-messages)
-        we introduced personal status messages for the first time, allowing to
-        share your current availability, mood or simply your favorite animal.
+        we introduced personal status messages for the first time, allowing you to
+        share your current availability, mood, or simply your favorite animal.
         With this release, we make setting your status even more simple and
         frictionless. A new "Set status" item in your user menu provides a fresh
@@ -118,6 +117,7 @@ features:
     - name: "Move ability to use includes in .gitlab-ci.yml from Starter to Core"
       available_in: [core, starter, premium, ultimate]
       documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#include'
+      image_url: '/images/11_4/verify-includes.png'
       reporter: jlenny
       team: verify
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/42861'
@@ -132,11 +132,12 @@ features:
     - name: "Run jobs only/except when there are modifications on a given path or file"
       available_in: [core, starter, premium, ultimate]
       documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#only-changes'
+      image_url: '/images/11_4/verify-onlyexceptchanges.png'
       reporter: jlenny
       team: verify
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/19232'
       description: |
-        A popularly requested feature, we're proud now to be offering the
+        A popularly requested feature, we're proud to now offer the
         ability within the `.gitlab-ci.yml` to use only/except rules for jobs
         based on when modifications occur to a specific file or path (glob).
@@ -159,14 +160,14 @@ features:
         and you have the ability to control the behavior of your software
         in the field via the feature flag within GitLab itself.
-        Feature Flags offer a feature toggle system for your application. 
-        They enable teams to achieve Continuous Delivery by deploying new 
-        features to production at smaller batches for controlled testing, 
-        separating feature delivery from customer launch. This helps reducing 
-        risk and allows you to easily manage which features to enable.
+        Feature Flags offer a feature toggle system for your application.
+        They enable teams to achieve Continuous Delivery by deploying new
+        features to production in smaller batches for controlled testing,
+        separating feature delivery from customer launch. This helps reduce
+        risk, and allows you to easily manage which features to enable.
         Note that this is an alpha feature being introduced for the first time,
-        so while we encourage you to check out the feature and provide feedback
+        so while we encourage you to check out the feature and provide feedback,
         we want you to be aware that the implementation could change in subsequent
         releases.
@@ -226,7 +227,7 @@ features:
         just got more powerful. Starting in 11.4, Auto DevOps now provides the ability to initialize or
         migrate PostgreSQL databases in your project.
-        Simply define a project variable to initialize or migrate your PostgreSQL database and Auto DevOps
+        Simply define a project variable to initialize or migrate your PostgreSQL database, and Auto DevOps
         will do the rest.
 # SECONDARY FEATURES
@@ -438,14 +439,14 @@ features:
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/47963'
       description: |
         Two-factor authentification is a de facto standard for signing up for any relevant web-based
-        application. At GitLab we understand and take this serious. Whenever you set up a two-factor
+        application. At GitLab we understand and take this seriously. Whenever you set up a two-factor
         authentication initially, we provide limited recovery codes that allow you to regain access
         to your account as a fallback.
-        With this release, we now support to download recovery codes via a new "Download codes" button
-        in addition.
-        Thank you for this contribution, [Johann Hubert Sonntagbauer](https://gitlab.com/johann.sonntagbauer)!
+        With this release, we now support download recovery codes via a new "Download codes" button
+        addition.
+        Thank you for this contribution, [Luke Picciau](https://gitlab.com/Qwertie)!
     - name: "Filter admin Runners view by Runner type and state"
       available_in: [core, starter, premium, ultimate]
@@ -464,6 +465,7 @@ features:
       available_in: [core, starter, premium, ultimate]
       gitlab_com: false
       documentation_link: 'https://docs.gitlab.com/ee/ci/interactive_web_terminal/'
+      image_url: '/images/11_4/verify-webterm.png'
       reporter: jlenny
       team: verify
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-runner/issues/3467'
@@ -476,28 +478,29 @@ features:
     - name: "Allow pipelines to schedule delayed job runs"
       available_in: [core, starter, premium, ultimate]
-      documentation_link: 'https://docs.gitlab.com/ee/ci/pipelines.html#delay-a-particular-job-in-the-pipeline-graph'
+      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/README.html#when-delayed'
+      image_url: '/images/11_4/verify-delayedjobruns.png'
       reporter: jlenny
       team: verify
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/51352'
       description: |
-        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
-        would have otherwise started, giving you control to implement
-        tasks that need to wait for a period of time to occur - for
+        It is now possible to set a job to start after a delay
+        via the `when` keyword in `.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
         other delays needed after performing some other action.
-    - name: "Skip Auto DevOps jobs based on license"
+    - name: "Skip Auto DevOps jobs based on feature availability"
       available_in: [core, starter, premium, ultimate]
       documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/'
       reporter: danielgruesso
       team: configure
       issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/48399'
       description: |
-        Starting in 11.4 Auto DevOps will now evaluate the license for the instance in which it's running
-        in order to determine which jobs to skip. This will result in faster Auto DevOps pipeline when
-        certain features are not in use.
+        Starting in 11.4 Auto DevOps will now evaluate the plan (GitLab.com) or tier (self-managed)
+        for the instance in which it's running 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 a cleaner view of Auto DevOps pipeline,
         showing you only the relevant jobs for your project.
@@ -514,7 +517,7 @@ features:
         common tasks such as diagnosing, deploying, and measuring infrastructure components.
         The JupyterHub app offered via GitLab's Kubernetes integration now ships with Nurtch's
-        [Rubix library](https://github.com/amit1rrr/rubix), providing a simple way to create devops
+        [Rubix library](https://github.com/amit1rrr/rubix), providing a simple way to create DevOps
         runbooks. A sample runbook is provided, showcasing [common operations](https://youtu.be/Q_OqHIIUPjE).
     - name: "Add manual entries for License Management"
@@ -530,7 +533,7 @@ features:
         directly in the merge request page. But sometimes project maintainers want to populate the
         list beforehand, so that developers already know if their changes are aligned with the policy.
-        In GitLab 11.4 we introduce the ability to add manual entries for License Management. Project
+        In GitLab 11.4, we introduce the ability to add manual entries for License Management. Project
         maintainers can prefill the policy in the **Settings > CI/CD > License Management** page by
         choosing from a set of common licenses, or add a custom entry to that list.
@@ -596,6 +599,7 @@ features:
     - name: "Geo UX improvements in Admin Area"
       available_in: [premium, ultimate]
+      gitlab_com: false
       documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/configuration.html'
       image_url: '/images/11_4/geo_admin_area_improvements.png'
       reporter: akaemmerle
@@ -612,7 +616,7 @@ features:
         On secondary nodes, a new "All" tab gives you a quick overview about the verification state
         of all projects.
-        Further UX improvements are in our pipeline!
+        [Further UX improvements](https://gitlab.com/groups/gitlab-org/-/epics/369) are in our pipeline!
     - name: "Geo improvements for SSH git commands proxy to primary node"
       available_in: [premium, ultimate]
@@ -624,10 +628,10 @@ features:
       description: |
         Making Geo as easy to use as possible is one of our constant goals to support widely distributed
         teams using GitLab. In [11.3](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/#geo-improvements)
-        we added initial support for proxying SSH `git push` from secondary to primary nodes.
+        we added initial support for proxying SSH `git push` from secondary nodes to primary nodes.
         With this release, we further improve the performance and usability of this feature, allowing
-        to clone and push to projects in a Geo scenario without having to update the remote URL manually.
+        to clone and push to projects in a Geo scenario without having to maintain multiple configurations or update the remote URL manually.
     - name: "Geo improvements"
       available_in: [premium, ultimate]
@@ -707,7 +711,7 @@ mvp:
   gitlab: tuomoa
   description: |
     Tuomoa added support for the very popular and highly requested feature
-    [GitLab Pages access controls](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18589)
+    [GitLab Pages access controls](#gitlab-pages-access-control)
     for GitLab installations from source. For updates on support for Omnibus
     installations follow this
     [merge request](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2583).
@@ -738,9 +742,7 @@ barometer:
     migrations we have introduced background migrations.
     GitLab.com migrations took approximately 34 minutes and post-deploy migrations amounted for a
-    total of around two minutes. Background migrations on the other hand are sidekiq jobs that will
-    run synchronously, for this release these migrations took around Z days to complete, no side
-    effects were expected nor present, these target older pipeline builds so newer executed pipelines are not affected.
+    total of around two minutes.
     GitLab Geo users, please consult the documentation on [upgrading Geo](https://docs.gitlab.com/ee/administration/geo/replication/updating_the_geo_nodes.html).
@@ -753,3 +755,10 @@ deprecations:
       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.
+  - feature_name: "Support for Prometheus 1.x in Omnibus GitLab"
+    due: GitLab 12.0
+    reporter: joshlambert
+    description: |
+      With GitLab 11.4 (October 22, 2018) the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab. Prometheus 2.0 is [now included](#prometheus-20-upgrade-for-omnibus-gitlab),
+      however the metrics format is incompatible with 1.0. Existing installations can upgrade to 2.0 and optionally migrate their data [using an included tool](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4).
+      Migration to 2.0 will be required in order to upgrade to GitLab 12.0.