How to handle the charts versioning
The charts don't follow the same version as GitLab itself and there's a reason why they probably won't.
We anticipate breaking changes we may need to introduce to the chart that would warrant a major version bump, and the requirement for these changes could completely block other development on these charts until completed.
We need to figure out a way to match the chart version with the equivalent GitLab one when we build a new version. For the time being, we're pulling master.
https://docs.gitlab.com/charts/development/release.html
Chart branch | GitLab branch | Chart version | GitLab version |
---|---|---|---|
1-5-stable | 11-7-stable | 1.5.x | 11.7.y |
1-6-stable | 11-8-stable | 1.6.x | 11.8.y |
This means that at every given time, /11.7
will include the 1.5.x
chart, and /11.8
the 1.6.x
chart.
Old description
The chart versions are created by creating git tags https://gitlab.com/charts/gitlab/tags. Those tags, refer to specific GitLab versions as seen in https://docs.gitlab.com/charts/installation/version_mappings.html.
- when do the charts get released?
- what's the nature between the patch versions
- timelines, freeze dates (same as GitLab?)
Proposal
There's a charts page about the versions https://docs.gitlab.com/charts/installation/version_mappings.html, and the Distribution team is thinking on making this automated. Maybe we can share a json/yaml file with the version mappings that we can both use. On our side, we can show this info on the docs site depending on which version you have selected in the dropdown.