Our updates have taken one full-time engineer for 2 weeks plus an additional 2 weeks total of various people's time for each upgrade. It's worse if we skip a version.
We dedicate probably 3-4 person-months per year to staying updated, but it's well worth it. As an investment its ROI is easily 100x.
Your effort estimates line up with mine, but I'm not sure about the ROI (but it's been a few years and I was pre-fortnite).
We made limited changes to Unreal source, but I think we made more changes than we had to. We had our middleware, we fixed bugs (none upstreamed via github due to company policy), but we also introduced new features varying from necessary for the project (instanced mesh rendering) to unnecessary (fancy logging). Every upgrade, I regretted most of the changes we made.
But also, it seems like every upgrade our data assets and blueprint script would get less stable and cause weird infrequent crashes in the blueprint/uscript interpreter.
Do you use bleeding edge features? I recall being wary of anything that hadn't been around for a few updates.
All changes to the engine are required to be wrapped with a special comment tag indicating the author and explanation of the change, so that it's evident in a 3-way merge window how to resolve if there's a conflict at engine-upgrade time.
At a previous company we used Enlighten and Simplygon both of which made changes to engine source, and those were a nightmare to deal with. We had several source branches set up specifically to deal with 3-way merging at all steps of the way.
We also implemented things like instanced skeletal meshes, an improved navigation system, and additional shader passes. Those were all very complex to upgrade especially when Epic had refactored the underlying systems.
We don't use features that are experimental in shipping code.
Middleware migration headaches are everywhere, regardless of the chosen stack.
It's been a while since I've been in the industry so maybe things have changed but last time I was there unit tests weren't even a thing. Smoke tests where if a set of levels loaded and didn't crash was considered success from an automation validation standpoint.
Companies cling to 40 year old COBOL because there's nothing stable enough to migrate to.
There's also a lot more to consider than just how long an LTS lasts, like the degree of backwards compatibility and the rest of the ecosystem. It was my understanding that project jigsaw broke a lot of that, but I'm outside the java world so i didn't really keep up. .net for instance was great until recently because they had decent support lifetimes and kept backwards compatibility, so updating to the latest was at least simple and painless. Even trying to do those upgrades was like pulling teeth inside corporate environments though.
Ubuntu cuts an LTS release every 2 years, but they support them for 5 years.
It appears Oracle supports Java LTS releases for 8 years.
2 years is a reasonable time to expect that the user will move on to the next LTS browser version. 2 years is not a lot of time to release a game without having to upgrade the engine mid-project.
Oracle just extended it due to Java 9 being our Python 3, which is kind of pointless because all the packages that matter have migrated already.
But enterprise being enterprise, there are plenty of projects only now migrating to 8, and then there is that little robot that isn't even fully compliant with 8.
And here's an official Oracle doc regarding Java support where they show Java 11 (LTS) being supported until either late 2023 or late 2026 depending on your support level. I'm not sure they provide free support anymore, or maybe that's limited and what you're referring to?
1: https://en.wikipedia.org/wiki/Java_version_history
2: https://www.oracle.com/java/technologies/java-se-support-roa...
Java has several commercial and free implementations, so every Java vendor is free to choose their own timelines, I was only talking about the free layer of OpenJDK/Oracle, as that is what many around here understand as Java.