Request for LTS versions of UE and marketplace assets.

General Feedback & Requests
, , , , , , , , ,
41

here’s the place for anyone that wants to contribute.
the only three guidelines are:

  • be kind,
  • only make PRs for things you’ve tested that work and don’t break other features.
  • No new features, only bugfixes.

this is the lts for 2025.
https://github.com/jerobarraco/UnrealEngineLTS/tree/lts-2025

anyone is invited to participate on the PRs. I would prioritize fixes over quality.

here’s the wiki, feel free to document things there.
https://github.com/jerobarraco/UnrealEngineLTS/wiki

here are the issues. feel free to add any concern here. it could be ideas, discussions, or bugs to be fixed, tasks,etc.
https://github.com/jerobarraco/UnrealEngineLTS/issues

1 Like
42

Wait, before we do that, We should settle on the “most stable” branch of UE5. And work from there. People are saying 5.5

Also, we should evaulate the direction of where it should go. Do we try to backport every update epic makes? That seems an awful lot of work. Instead we should focus on existing stuff frist. I personally want to start off of a “minimal” project which has all the plugins disabled and work from there. Enabling stuff 1 by 1, ( im not saying fix every plugin but just to keep bloat out of the engine) There is a github repo for it. @nande

43

i thought about it. but since it’s an lts i think it doesn’t make a ton of diff between 5.5 and 5.6.
i’ve chosen 5.6 since it has some seriously useful performance improvements.
and i expect epic to release a point update for 5.6 soon, (in fact in linux i already have 5.6.1), so it’s better than it was. and 5.7 is on the way for the fest i think.
we can go with 5.5 if that suits people better. but id rather 5.6 as 5.5 is on its way out. atm is just a branch so i can change it quick.

i think its ok if we just start with whatever we can, and we figure things on the way. trying to figure everything at the start is a good way to loose time imnsho.
i’ve set up a wiki, my thought is we can write out our preferences and goals there and other docs for newcomers.

i also thought about how to split the work. and since this is a community effort i think the fairest strategy is simply let people focus on whatever they want to work.
if someone really wants to work on X plugin then fine. i won’t oppose progress is progress.
maybe we could have global suggestions for people coming by,

as for disabling plugins, i think it would be nice to have everything as the release version, otherwise it would take months or years to catch up and little people will use it. i definitely don’t have the time for that.
i think it’s ok if we start with the base of what epic already has, as is, so by default is as good as epic’s. and whatever we include it’s a bit of an improvement.

not features, only fixes. and yeah, backporting will require quite some work. we would have to be careful to backport only the things that don’t break other things nor add new features.
it’s another reason to begin with 5.6, less backporting to do.

i agree with you though, i personally would focus on the core elements. those are the most important and what more people would benefit. though i usually balance cost/benefit. so if there’s an easy fix somewhere i would do it anyway. and if a core thing is very difficult i might find the way to fix it in chunks.

the only thing i’d like to do is to only merge things that have been tested and ensured that works and don’t break other stuff. it’d be nice if people could pull any updates from the lts and test before a pull request.

if anyone wants to submit a fix just do a pull request. i will add other people with time.

i don’t know what you mean.
the branch i shared is a github repo. and it’s linked to the official epic one. so it can pull changes quickly as well as make pull requests to epic.

and finally an optional but nice thing to do, would be to make a pull request from each fix in our lts to the official epic main. that way we don’t need to worry about it for next lts.

i would love to give in this project as much freedom to people as possible. since it’s a contribution. i don’t want to put too rules that don’t need to be there. just to reduce friction. some people might only contribute one fix. and that’s a win for me.

i’ve added the links to the wiki and issues above. i think it’d be good to discuss our direction and goals in the issues. so that we can keep each topic separate and organized.

44

i too like the perofrmance improvements of 5.6 but rn its too broken to be used, so we either wait for 5.6.1 and confirm it works or we go straight 5.7 but that will likely release again with broken stuff so this could be a slippery slope.

Also the minimal github repo i was talking about:

45

In short: i feel a bit reluctant to take a decision with only two of us and not a clear idea. Would someone else like to chime their opinion?

5.6.1 seems to be already available in 5.6 branch which is the one ive bosed on.
They havent released it yet but its there.
I imagine its still waiting for more fixes. So an honest thought is that 5.6 is not settled yet so maybe it can make things worse for us.
Agree we would likely need to test it to know if its stable.

The way i see it is, its just a starting point, it doesnt really matter that much wether its more or less stable than 5.5.
The idea of an lts is that it lasts for a few years, id say at least one, maybe two. So starting with an outdated software is going to cost us in the future. Specially when moving to the new lts.

Im working on my project on 5.6 and its not unusable. It has not broken anything of the things i use. Ive heard a lot of people saying that is worse than 5.5 but i struggle to take it at face value.

People are still using 5.6, ive seen a few " ive switched to 5.6 now i cant go back".
So those people, who needs it the most, wont be able to use the lts.

Re minimal repo.
I tried reading the article but its much too long for the time i had and i cant infer what of it you are trying to communicate.
Could you explain a bit, consicely, what do you prefer and specially why you think is a good idea? Ideally without ai, since i dont understand ai speak.

Still not knowing what you propose, i state my pov a bit more.
I think ideally we would benefit from being as close to origin as possible.
Ue is a huge ecosystem.
Any distance whether in scope or shape, will be a load to maintain, and also contradict our goal of stability.
Its quite likely that if we “disable” a plugin we either:
Break peoples projects.
Or live in a small island, make fixes that then break those disabled plugins.

I think ideally an lts’ goal should be: provide the same experience of the main release, but with less bugs. Thats all.

I think we should have a clear goal like that to ease agreements and friction.
And maximize our chances of success.

If the lts differs from main branch in features or workflow is going to make it hard to adopt (for gamedevs), which is going to blocks us from getting more contributions.
We might miss out on contrubitons to other areas. Like i stated above i dont want to block those.
It will also make it much harder to move the fixes to a new version.

As a recovering perfectionist, perfect is the enemy of good (and done). (Nothing is ever perfect or done in software or life).
I dont agree with having a goal of “if its not perfect we wont release it, (hence disable)”. I have too many reasons why. And i wouldnt participate in such project.
I think “ue release, but with less bugs” its much more valuable, and worthy to me.
At least to begin with.

Again we dont know what we can do yet, so reducing the area will only blocks us further. If we allow contributions for all areas, we can backport simple fixes more acccesible to us (at least to me).
And my experience with making open source projects is that, you need to have low hanging easy tasks for newcommers. If there is too much friction you starve the project. (And by too much i mean any).
Ue code is like a heavy airplane that we are pushing by foot.

46

Why i say it doesnt matter that much?
Bucause epics changes to 5.6 will stay, and we wilr have to deal with them.
5.6 is not as experimental as 5.0 its much much more stable than 5.2 even.

47

Ok look, the way i look at it is very simple. Squeezing as much performance and maintaining a lightweight approach (aka cutting out plugins that i dont use, idk arcvis stuff just to name something) while mainting the most graphical fidelity. I dont necessarily plan to “move to the next lts” but just to have 1 reliable build of unreal that is very performant and also sports a nice package of features.

Also, personally im not looking to support a broad audience but more like this specific vision of the branch. Also, regarding 5.6, as much as i want to love it, its animation ui baceme cluncky, they literally did not include swarm in the relase, and people have been reporting its generally been an extremely buggy release.

The final goal is UE4 level of performance on UE5 to put it shortly.

48

i see. thanks.

i think than an lts is not what you’re looking for. you should make another fork that is geared towards performance.
the goal of an lts is basically stability over along period. not performance. lts stands for Long Term Support. perf is an orthogonal goal, and i love it, but it would make it really difficult to mix both.
there are other people interested in that approach. specially the people who follows ThIn. they were planning on having a fork for it too.

disabling plugins won’t really translate to performance most of the time. there are many plugins that don’t impact performance.
but more importantly you can, and should, disable all the plugins you don’t use in your .uproject. and that will provide you with the performance and memory improvements you might be looking for.
in my project i’ve disabled all plugins that i don’t use.
and when i submit a plugin to fab, they require (it’s a cause for rejection), to manually disable all plugins you don’t use.
so i don’t think we really need to do anything about that in the actual lts repo.
it’s also impossible to know which plugins people are using. there’s a reason why ue has the philosophy of having “everything enabled by default”. as one becomes experienced sometimes one wants to have everything disabled. but there’s a reason for that, i think if we try to change that it would be an uphill battle. and people who expects ue to work in a way would be frustrated with the lts.

49

Here is what I think:

At first I used to think that long term support vs short term support release cycles were more for complete operating systems. But after seeing that Blender has also applied this philosophy to some of their release branches, and after what I have witnessed here in Unreal forums, I wonder myself if this engine could benefit from this kind of releases. I develop:

Problem:

Unreal Engine is big, widely-featured, very powerful, and most important, highly adopted in several industry fields (cinematography, automobile industry, gaming…). As intended.

As this engine has a lot of features it’s also prone to suffer from having a lot of bugs. Knowing this, it seems that its current release cycle works more or less like such:

When several bugs are found, Epic first uses to release a new .1 version right after the previous one, committed only for bug fixing. Example, months after the release of 5.6, the 5.6.1 appeared. This release was only for bug fixing.

The thing is that, in this 5.6.1, some problems were solved but some others remained. And after this, no more bug fixing versions were released. What seemed to happen instead was that it was planned that after 5.6.1 version, remaining bugs were scheduled to be adressed in 5.7.

And later, when this version was released it happened that:

Some of the remaining problems in 5.6.1 were solved.
Some of the remaining problems in 5.6.1 still remained unfixed.
Some new features were added.
New features provoked even newer bugs.

Therefore, what seems to happen, is that beyond certain point, Epic prefers instead of doing bug fixing, to release a newer version, trying to adress remaining bugs in said newer version. But happening that since this newer release contains newer features, even NEWER BUGS will appear.

So the eternal cycle repeats again and again, and after every new release, you end up seeing that the latest version has:

Fixed some of the previous problems.
Not fixed some other of the previous problems.
Added new features. Probably some of which you don’t need.
Introduced newer bugs.

So users end up asking themselves: ‘What it’s going to come fixed and what is going to come broken this time?’.

But if you think that this is a pain for the regular users, stop for a second and wonder yourself how this could be impacting big COMPANIES.

As companies works for production, finishing developments becomes critical, so I think that what would surely happens in most situations is that when a new version is released, they probably give it a try, JUST TO CHECK THE BUG FIXING, and when they discover that new bugs appear and not all the previous have been fixed, they just chose to stick to their current version for months. If not years.

Think that this is a natural consequence: The engine is massive. High amount of stuff is going to be to have a high amount of human error…There is a lot of systems to develop, a lot of systems to revise, a lot of systems to mantain…

So thinking about all of this, you can see why Blender choose to have LTS releases, as this means basically, that if you have a good release, you can declare it as a long term support version, and these versions are promised to receive patches that will serve just to do THE BUG FIXING, being frozen in the addition of new features. So studios can stick to it for some time and rest assured: in every path bugs will be fixed, but no new ones will be introduced.

At the same time, of course, you also mantain the other branch, with the usual releases, that can contain new features + new problems. This way, for the cases in which companies DO NEED stability, and quality assurance will receive it, as working as secure as posible + to finish their productions are the main priority for them.

So I’m with yes.

1 Like
50

Summarize it without AI :grinning_face:

2 Likes