Hi All,
I would like to upgrade Gitlab from 10.6.4 to latest stable version. Could anyone please suggest one stable version from 12.
The only sensible thing to recommend is the newest version.
Now I can see that the patch release 12.4.2 has been announced, I haven’t had the time to try that out yet (it wasn’t released when I went home from work yesterday, and it’s only been 10 minutes since I arrived at the office today), but 12.4.1 worked fine.
GitLab releases a new minor version every month, so no version is more stable (in the sense of “doesn’t change”) than that, and if security problems or serious regressions are found a security or patch release might come in between, but I believe only the last three minors (currently 12.2, 12.3 and 12.4) are supported (in the sense that they will have that kind of problems fixed).
1 Like
@grove, Thanks for the info, Could you please let me know the less bug reported version in 12 series.
I have no idea, I’m just a user so I don’t see bug reports, but the only things that has affected me was in 12.0.0 and 12.1.0.
Thanks for the detailed info, As per the Gitlab recommendation , i would like to upgrade to 12.0.2. Please let me know your views if possible.
It’s certainly possible, but in all likelihood stupid. It’s a version that’s not supported anymore and all the later versions in the 12.0 series (i.e. 12.0.3, 12.0.4, 12.0.6, 12.0.8 and 12.0.9 - there were no 12.0.5 or 12.0.7) were branded as security releases, so 12.0.2 has security problems. In addition the 12.0 series is no longer supported.
Please rethink which version you want.
Thanks for the update. So in that case, i could see the 12.2 series is stable and good to go with 12.2.4.
10.6.4 to 11.3.4 and then 12.2.4. please comment .
Once again you’ve selected a version that isn’t the latest release in that minor series, and which has known security bugs.
Yes, the 12.2 series is supported, but that just means new security/patch releases are made, if you from the start choose to go with an old release I doubt it will matter to you.
On the other hand: The 10.6.4 you run right now has security problems. There was a 10.6.5 and a 10.6.6, both labelled as security releases, so maybe your requirements are very different from what I can imagine, but then you’ll need to explain them more clearly.
And a comment on your upgrade patch: Why do you think 11.3.4 is a good intermediate step? 11.3 is not the last minor series with the 11 series, and 11.3.4 is not the last patch release in the 11.3 series.
There are plenty of threads on this forum about upgrade paths: find one of them.
Hi Grove,
The actually requirement is to upgrade the Gitlab version from 10.6.4 to the latest stable version. So i would like to choose one stable version to upgrade. Hopefully the 12.4 releases is still happening and there are chances to report many bugs. So i would like to choose one stable version from 12 series.
Hopefully the upgradation cannot done directly from 10 to 12, so i would like to choose one 11 version to upgrade first and then move to 12.
The current instance which we use is very huge (30K users , 36K projects. etc… )
But what is your definition of “stable”? As I said in the first post:
The only sensible thing to recommend is the newest version.
I would prefer it if someone else would maintain a stable version of GitLab with security patches backported (like Debian maintainers do with their stuff - personally I run Debian Stable, and feel quite good about that even if it means I often run old software), but I haven’t found that, and I can see why that would be hard with GitLab. With GitLab you could probably skip every second minor (or possibly 2 out of three, but then you would have no period of overlapping support between two versions you run), Both I see no point in doing that over just running the newest version and upgrade when a new version is released.
First, you can’t upgrade from 10.6.4 to 12—you will have to upgrade to the latest 11 first. I know for a fact that a direct upgrade to 12 will run into database problems.
After that, the latest version of 12 has the most bug fixes. I don’t know why you’d ever consider another version. Sure, every modification has the possibility of introducing other problems, but on the whole the latest version will always be the most stable.
For a GitLab Omnibus instance, we suggest upgrading to the latest minor version before upgrading major versions. Major versions may contain backwards-incompatible updates.
To upgrade from 10.6.4 to the latest 12.4.2, the following upgrade path should get you there without any problems:
10.6.4 > 10.8.6 > 11.11.8 > 12.0.9 > 12.4.2
To play it safe, I suggest taking a backup of the instance (gitlab-rake gitlab:backup:create) before upgrading.
Thanks for the detailed info and its helps me a lot. Is there any dependency in runners version. Is we need do to use 12 series of runners ?? Or old version also support for Gitlab 12 series ??
Yes, you should be using the latest Gitlab Runners with the latest versions of Gitlab:
“The GitLab Runner version should be in sync with the GitLab version.”
https://docs.gitlab.com/runner/#compatibility-with-gitlab-versions
See the Changelog for detailed Gitlab Runner versioning:
Thanks for the info,When i pulled new version of runner using below command and register to gitlab. But the jobs is in stuck state even if enabled the runner but the runner version 10.6.1 is working fine.
docker pull gitlab/gitlab-runner:v12.3.0
A small configuration change done and not its working fine.
1 Like
Hi All,
There is an important suggestion is required. Once i upgrade Gitlab from 10 to 12 and if i wanted to rollback to old version. How could i achieve that without any problem.
Seems the database upgraded to 10.8 in latest version.
AFAIK rollbacks over major versions are not supported. If you’re planning to do so, keep a full backup snapshot from your VM before upgrading.
Have seen a command in Gitlab “revert-pg-upgrade” . Will this command help me to downgrade the postgres from 10.8 t0 9.6.
Unfortunately I don’t have experience with maintaining these old versions. Yet again, take a backup of your server/VM and then try it out, I’d say 