4 ms·
> how contrived the upgrade paths are: https://docs.gitlab.com/ee/update/#upgrade-paths https://docs.gitlab.com/ee/update/#upgrade-paths Thanks for your feedba
by dnsmichi 5y ago
> how contrived the upgrade paths are: https://docs.gitlab.com/ee/update/#upgrade-paths https://docs.gitlab.com/ee/update/#upgrade-paths
Thanks for your feedback, agreed. I've created an issue https://gitlab.com/gitlab-org/gitlab/-/issues/353862 https://gitlab.com/gitlab-org/gitlab/-/issues/353862 - please add additional thoughts and suggestions there as well. Thanks!
- KronisLV 5y agoWell, i don't think that there's actually that much that can be done here, since that page does contain adequate documentation and a linear example migration path: 8.11.Z -> 8.12.0 -> 8.17.7 -> 9.5.10 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15 -> 14.0.12 -> latest 14.Y.Z It's just that the process itself is troublesome, in that you can'd just go from let's say 11.11.8 to 14.6.5 in one go and let all of the thousands of changes and migrations be applied automatically with no problems, as some software out there attempts to (with varying degrees of success). Of course, it's probably not viable due to the significant changes that the actual application undergoes and therefore one just needs to bite the bullet and deal with either constant small updates or few and longer updates for private instances. But hey, thanks for creating the issue and best of luck!