At work we are working with version 5.6 and I have been asked to upgrade the project to an LTS in the near future. I am wondering what version of 2018 I should use since the 2018 LTS is coming out soon.
Do I just use the latest version that is available of 2018?
Is it a beter idea to take the first version of 2018 and update to the LTS when it becomes available?
Should I use the 2017 LTS to try and port first?
Unity 2018.3. Unityâs LTS are merely renumbered .3 releases.
20xx.4 LTS is just 20xx.3 with bug fixes and a more rigid protocol for developer check ins. So if you want to go to 2018.4 LTS as soon as it releases, then you go to the latest 2018.3.
A 5.6 project will likely have a smoother upgrade to 2017.4 though, as far fewer things have changed. For example, 2017.4 still has the legacy particle system which your project might still be using, but 2018.3+ will require you to replace all those particle effects.
You might want to take it incremental, start with 2017 fix the issues (we didnât have any between 5.6 and 2017 but alot between 5.5 and 5.6). And when 2017 works move to 2018.
just a word of caution, it can be dangerous to upgrade a large project to a newer version âjust causeâ. you may run into weird bugs and issues you cant easily fix, but hey who knows, everything might work perfectly fine. there might be some functions that are deprecated or changed, so then you have to go back and do a lot of refactoring because the new one doesnât work exactly the way you expected it to when it was designed.
generally i only recommend upgrading mid-project if there is some brand new feature that you desperately need, and even then you should evaluate if its worth it because you will need to figure out how to use it and implement it into your existing project. i say its best to finish up the project in one version and then use a newer version for your next project.
not saying you should never upgrade, if its an ongoing project that will never technically be fully finished then you will need to upgrade from time to time. just be careful when you do it. make a new branch or a backup copy and test it out first so you know what to expect and dont ruing the whole project.
but anyways, back to your original question, if you need or want to do it soon, go with the 2017 lts, but if its not a priority then you might as well wait till 2018 lts. but then again once youâve upgraded it from 5.6 to 2017, going to 2018 shouldnt be much of a hassle anyways.
Thatâs a bad tip that will ruin someoneâs business at worst
which tip? mine? and if so how?
i dont claim that everything i say is 100% the best correct way, but i have a reasoning for it and can explain why i do it that way. to just say âthats badâ with no explanation of why or what is better is not very helpful.
i had a bad experience upgrading versions mid project once, so maybe thats why i stick to this idea now, and maybe things have gotten a lot better since then.
Yeah, but not doing it is worse in most cases. Itâs only in very limited small projects itâs good advice not to upgrade.
my experience is limited to small hobby projects. but how can it be worse in most cases to not upgrade mid project? it seems like theres actually less risk in upgrading in small projects actually, as in large complex projects there are way more moving parts that can break.
im not saying youâre wrong, im just saying i still donât understand your reasoning and you havenât really explained it.
Yeah, and thatâs why itâs a continuous effort
Large games and large studios typically will updated only if needed. Sometimes it is a requirement. My last title was 5.x for a very long time (I believe up until last year). It was a huge game and a big title. It went. at one point, over two years without an update to core tech, because the risk wasnât justified. (and as a bonus we skipped two years of Unity bugs) And most of the big games are like that. Mobile is bit more volatile because of platform/market dependencies.
Ultimately, you will have to determine the value in upgrading. Based on what you are willing to risk and what you are willing to spend. If it is purely to upgrade to current version, the best way is test and figure out how much work is involved. Ideally going as high as possible in terms of maintenance is a good idea. Try 2018.x and see what happens. if it is just too much of mess, try it incrementally. Do 2017.x first, get it solid and then try 2018.x again. Also, hopefully you already know some pinch points based on large features. (like legacy particles or older UI). Clone or dupe your project and jump and see what the landscape is like. Once you get a good idea and can thourgly test your project and know a) what you are looking at, and b) certain you want to do it, you can branch and do an upgrade if that is what you determine. Also once you jump in, you can start asking others about specific problems you encounter, if you need to.
But two very important things to bear in mind in when choosing:
A) is NEVER a requirement or best practice by itself to upgrade your tools, and
B) NO ONEâs input is more important than your own. You know your project, itâs needs and your available resources better than anyone else.
Good luck.
A) is false. B) I can agree on
You may not agree or understand that point, but as you are a small hobbyist first time game developer working on completing your first game, it is important to qualify your opinion based on that context. All development choices are contextual. There are no absolutes, regardless how hard to try to claim there are. Once you have experience you will better understand that.
Your constant claiming absolutes (on the same topic, over and over and over), is starting to border on trolling. Please stop claiming âtruthsâ or claiming others as âfalseâ without qualifying that it your opinion. Last warning.
You are claiming the opposite, stop trolling. Look, the industry is notoriously bad at QA. This is just one of many reasons why you are bad at it.
I was the chief architect for a system at a major bank, it started itâs life on .NET 3.5 and MVC 1.0 and is now on NET Core 2.2 and Angular 6.
Several hundred developers have come and gone over the years. Large systems like that wouldnât be possible without continues efforts.
Are not the same as games.
No, but very similar and most correlate in my experience. Automated testing is harder for games. At least if you want good relevant tests.
Also what about sequels, if you do not maintain your game you might be forced to start over for the sequel. Iâm not saying you canât skip updating engine. But itâs hard to forsee all scenarios, and atleast have a migration branch and you do not need to guess what the effort will be.
Thatâs how we do it, we even have 3 versions of the game right now, one on 2017 one on 2018 and one on 2019, probalby will scrap 2018 soon when 2019 becomes a bit more stable. Might not even release to production on 2018 at the end of the day
Experience that is very limited. Youâre correcting someone who has experience working on big teams when your team consists of two or three people. Better yet itâs a game that is about as successful as any other hobby game made for giggles⌠which is to say itâs not successful in the slightest.
https://store.steampowered.com/app/517020/Virtual_Warfighter/
https://steamspy.com/app/517020
Worrying about sequels before you have had even one successful game is definitely putting the cart before the horse.
Pleas also link something he has been in charge over at the same time will you.
Edit: btw I must ask, you are aware of that domain complexity does not correlate to number of installs?
Check his profile. His âhomepageâ links to one game and his signature has a link to another.
Are you aware that a multiplayer game with one concurrent player is basically a failed game?