Update the release terminology on the old handbook repository
With patch release being repurposed to include bug and security fixes, the term 'security release' has been deprecated. The old handbook repository needs to be updated to account for this:
Entries encountered:
./source/direction/saas-platforms/delivery/index.html.md:102:We support this unofficially today in delivery thanks to the improvements we’ve made on the security releases last year.
./sites/uncategorized/source/security/faq/index.html.md:92:**How does GitLab handle security releases?**
./sites/uncategorized/source/security/faq/index.html.md:94:GitLab releases patches for vulnerabilities in dedicated security releases. There are two types of security releases:
./sites/uncategorized/source/security/faq/index.html.md:95:* Monthly scheduled security release that is targeted to go out a week after the feature release (which deploys [every month](/handbook/engineering/releases/))
./sites/uncategorized/source/security/faq/index.html.md:96:* Ad-hoc security releases for critical vulnerabilities. The fix for every vulnerability is backported to the current release, and the 2 previous `major.minor` versions.
./sites/uncategorized/source/security/faq/index.html.md:98:To help you understand the vulnerabilities that were fixed, a blog post accompanies each security release and includes a brief description, the
./sites/uncategorized/source/security/faq/index.html.md:99:versions affected, and the assigned CVE ID for each vulnerability. Feature and security release blog posts are located in the [`releases` section of our blog](https://about.gitlab.com/releases/categories/releases/). In addition, the issues detailing each vulnerability are made public 30 days
./sites/uncategorized/source/security/faq/index.html.md:100:after the release in which they were patched. It is highly recommended that all customers upgrade to at least the latest security release for their
./sites/uncategorized/source/security/faq/index.html.md:103:To be notified when a security release is released, the following channels are
./sites/uncategorized/source/security/faq/index.html.md:111:We do not offer customers advance notice of security releases. We have two principal reasons for this:
./sites/uncategorized/source/security/faq/index.html.md:113:* We mentioned above that regular security releases are targeted for release one week after our feature release (which deploys [every month](/handbook/engineering/releases/)). We set the date for the security releases after the feature release, and we’re not always able to accurately pinpoint an exact release date within that seven-day window (due to manual processes that still exist and potential, unforeseen delays that can arise).
./sites/uncategorized/source/security/faq/index.html.md:115:* We often perform critical security releases ad-hoc, especially in cases involving a great deal of urgency. In these scenarios, providing a pre-announcement is difficult and could even delay a critical fix, putting our customers at risk. Instead, we typically release as soon as we have a fix and notify via our [security notices mailing list](/company/contact/).
./sites/uncategorized/source/security/faq/index.html.md:117:We understand security releases and critical fixes aren’t always convenient for our users. We’re continuing to review and refine our communications processes surrounding critical security incidents and have set a goal of a [6 hour window for turnaround on customer communications related to an S1 severity vulnerability](/handbook/security/security-operations/sirt/security-incident-communication-plan/#turnaround-on-customer-messaging) to get critical information into users’ hands as soon as possible.
./sites/uncategorized/source/security/faq/index.html.md:119:**The best way to stay on top of security releases and critical fixes is to subscribe to our [security notices mailing list](/company/contact/).**