GitLab Dedicated releases and versioning

GitLab Dedicated follows a specific versioning model and release schedule for your instance to balance stability with access to new features and security patches.

Versioning model

Your instance runs on the previous minor version (N-1) relative to the current GitLab release. For example, when GitLab 16.9 is available, your instance runs GitLab 16.8.

This approach provides:

• Stability: Additional time for testing and validation before deployment.
• Security: Critical patches are still applied promptly through emergency maintenance.
• Predictability: Regular upgrade schedule aligned with monthly release cycles.

New features become available on your instance approximately 1 month after their initial GitLab release.

Check your GitLab version

You can check your GitLab version through GitLab itself or through Switchboard.

To check your GitLab version:

• In GitLab: On the left sidebar, at the bottom, select Help ( ) > Help, or visit https://your-instance-url/help directly.
• In Switchboard: See tenant overview.

Release rollout schedule

Your instance is upgraded during scheduled maintenance windows according to a staggered timeline that begins 5 days after each GitLab release.

Upgrades occur during your assigned maintenance window according to the following schedule, where T is the date of a minor GitLab release:

For example, GitLab 16.9 released on 2024-02-15. Instances in the EMEA and Americas (Option 1) regions were upgraded to 16.8 on 2024-02-20, 5 days after the 16.9 release.

If maintenance is deferred due to operational constraints, upgrades occur in the next available maintenance window.

Update frequency

Your instance receives regular updates during your preferred maintenance window:

Monthly updates include:

• One minor release
• Two patch releases

Additional updates might include:

• Critical security patches through emergency maintenance
• Infrastructure improvements
• Performance optimizations

Patch validation timeline

Critical patches follow an accelerated timeline to ensure security vulnerabilities are addressed quickly:

1. Development: Bug fixes must be merged into the stable branch at least two business days before the expected patch release date.
2. Patch release: A patch is released for a security vulnerability or critical bug.
3. Validation (0-24 hours): The patch is validated in staging environments.
4. Emergency deployment: The patch is deployed to your instance through emergency maintenance procedures.

Patch release schedule

Patches are released twice monthly on the Wednesdays before and after the monthly release week. The monthly release week is the week containing the third Thursday of the month.

Non-critical patches are included in the next scheduled maintenance window.

Request a backport

If you need a specific fix that hasn’t been backported to your version, you can request a backport of the change.

To request a backport:

1. Submit a support ticket with:
   • A link to the merge request or issue containing the fix.
   • The business justification for the backport request.
   • A description of the impact if the fix is not available.
2. Wait for a response about whether the backport is approved.

If approved, the backport is included in your next scheduled maintenance window.

Related topics

• GitLab Dedicated maintenance operations
• GitLab release and maintenance policy