@@ -9,6 +9,8 @@ Internal releases do not contain new features, feature flag changes, or incomple
For the general release policy framework including ownership, exception process, and escalation paths, see the [Release Policy](/handbook/engineering/releases/#release-policy) section.
If the internal release is not the result of a security incident, an [incident must be declared](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident). The incident should be marked "Planned Activity" and be S1 or S2 given the need for an out-of-band patch. To uphold the reliability and availability of the GitLab platform, completing an [incident review](/handbook/engineering/infrastructure-platforms/incident-review/) and an [FCL] is mandatory.
## Internal release overview
Internal Releases are private releases of GitLab for our single-tenant SaaS instances. They allow us to remediate
@@ -91,8 +91,9 @@ At GitLab, there are two types of patch releases processes:
[`critical` vulnerabilities](/handbook/security/product-security/vulnerability-management/sla/) will be considered critical patches.
1.**Unplanned**: An immediate patch required outside of the planned patch release cadence to mitigate a high-severity (critical) vulnerability. These ad-hoc patches
are the result of an incident, they require a [security RCA](/handbook/security/root-cause-analysis/) done by the team that introduced the high-severity vulnerability and forced an unplanned release. The PSIRT
team is responsible for assessing the vulnerability, working with engineering to decide on the best approach to resolve it and coordinating with Release Managers
on a timeline for the release.
team is responsible for assessing the vulnerability, working with engineering to decide on the best approach to resolve it and coordinating with Release Managers on a timeline for the release.
**NOTE** - If the unplanned patch is not the result of a security incident, an [incident must be declared](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident). The incident should be marked "Planned Activity" and be S1 or S2 given the need for an unplanned patch. To uphold the reliability and availability of the GitLab platform, completing an [incident review](/handbook/engineering/infrastructure-platforms/incident-review/) and an [FCL] is mandatory.
