[joshlambert]

Hi, I'm a PM for our linux packages. I'd love to learn more about the cryptic issues and vague errors mention.

We've put a lot of effort towards making the upgrades as painless as possible, with few surprises. One way we've achieved this is by requiring users to update to the last minor version, before making the jump to the next major version, as you note. The reason for doing this, is that we add a lot of validation to that last minor package which checks for any deprecated features/configuration.

This way if you try to upgrade with a configuration that would result in GitLab no longer functioning, we abort the upgrade and tell you exactly why, leaving you with a functional instance in the interim.

[flocial]

It was a while ago but the upgrade was from 9 to 11. The first problem was the error message didn't give me a simple command to go step wise through the upgrade like:

---- Please upgrade to the next GitLab version before trying to upgrade to the latest. The command for upgrading to a previous version is as follows:

sudo apt-get install gitlab-ce=10.8.7-ce.0 -V

See the url below for available releases:

----

Going from 10 to 11 was even more difficult because the gitlab.rb file format changed and I was missing required information that was not apparent from the error messages after running "gitlab-ctl reconfigure" (I think the error was Chef related but my memory is hazy, below are the GitLab issues that finally provided a hint). This wouldn't be so bad if my GitLab 10 instance was working but after going from 9 to 10, all I got was a blank page so at this point I had no choice but to go all the way.

After finally replacing the gitlab.rb file with the template and adding back info from the old file, I was able to finally run reconfigure and update as needed. Of course, I was soon alerted by coworkers that their commits were suddenly being blocked for failing a commit pipeline. Overall it was not a fun experience and I'd rather not upgrade GL unless I have to but I also don't want to skip versions if I have to repeat the hellish upgrade process by manually babying the upgrade.

Issues referenced: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3610 https://gitlab.com/gitlab-org/gitlab-ce/issues/46219 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2153

[joshlambert]

Thanks for the additional information. The `git_data_dir` and gitaly configuration changes are indeed why we've started requiring moving to the last minor version first. The 10.x to 11.x upgrade was the first major upgrade with these checks, but it doesn't look like we captured all the possible scenarios. (We did prevent a few upgrade failures though, based on customer feedback.)

It is very important for the team to ensure upgrades are smooth. Right around 50% of our installations are running a version at most 3 months old, and we want to continue to improve that number so everyone can take advantage of the latest fixes, features, and security updates.

The team has opened another issue to explore ways to make it more apparent which version should be upgraded to: https://gitlab.com/gitlab-org/distribution/team-tasks/issues....

[meks]

Thank you for the feedback.

We are currently working on upgrade testing for single-hop upgrades. We are hoping to have this for 11.9 going forward.

This effort is currently being tracked here https://gitlab.com/gitlab-com/www-gitlab-com/issues/4852