Updating 5.6 to 2017/2018

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?

 

From a mobile POV:
On one hand, updating introduces risk, and there's no need to update if you don't need features/fixes from a newer version.
On the other hand, Apple and Google make new rules when they feel like it, and often those rules will require an update, so if your app's going to be out for years an update is nigh-inevitable.

So then the question become when to update.
Waiting until an update is required is perhaps the most efficient, but it means the process can be more painful and more time-constrained than doing it in advance.
Maintaining an updated branch and only switching over when needed is ideal for stability, but keeping multiple branches up to date (and tested) isn't without cost.
Updating ASAP means you're only dealing with one change at a time, but it also means you spend time fixing issues that would have been a moot point because you could have skipped that version entirely.

In practice, it's always been "update when required", because a task that takes time, might introduce bugs, and adds no value for the users or the monetization is always going to be assigned low priority until it becomes crucial.

And even in an ideal world, I would probably still go with "update when required" ... with the caveat that it becomes "required" as soon as an update-requiring rule is announced, not just when it's about to go into effect. And that if an update brings significant benefits it can be worth doing regardless of requirement.

 

It's not like skipping one version will automatically fix your migration problem in the next. If it didn't work in 2018 then there is close to zero chance it works in 2019 unless it was a bug in 2018.

But who knows, if you didn't find that bug in 2018 and reported it, it might be present in 2019 too, can't relay on others doing the work, we have reported a dozen bugs that unity then have fixed. Not all those related to migration but on top of my head I can think of atleast 3

 

For fun let me do a list from top of my head. So it's not complete

We started on 5.2 that would mean,

multi pass rendering only (we have seen two new modes since that, with the latest one Single pass instances completly eliminating the CPU overhead of stereo scopic rendering).

Mono 2 CLR with alot of allocation bugs and what not.

Broken mixed mode lighting with incomplete dynamic light casting and no specularity.

No SteamVR 2.0 support

bunch of third party assets wouldn't be able to upgrade like Obi rope

The list goes on

 

That's inaccurate data, I know because I was playtesting with our trainee

 

Just keep in mind this list won't be the same for other people. That the OP was able to stick with Unity 5.6 for this long is a good indicator of that, and let's not forget that they're upgrading solely because they were told to upgrade. There might be a legitimate reason, or it could just be another enterprise developer that thinks he knows something no one else knew.

 

Maybe OP can fill us in on what the reason was. And more importantly why it was done so late.

 

Because clearly wanting to know why it was done so late is more important than having a reason.

 

You game Devs have the same mentality towards package management? A large enterprise system can have hundreds of nuget packages. Just imagine waiting until all of those need update and update them all at once.

But, do not misunderstand me, my way of seeing it only works if you have a healthy continues integration and continues deployment strategy going. You can't blindly update and push to production

That's all from me for tonight, it's 3:30 here

 

I think it's been two years I'm telling you (and I know you think I'm a particularly sh**ty enterprise developer, because I don't follow the "best practices" blindly in my non-enterprise development work), that enterprise and game development are vastly different. I won't go into it again, you can go back and read our debates in the past if you like it.

 

Which industry you talk about, since you mentioned banking industry? Because I can point you exactly type of industry, which still runs control hardware (GEM80) and software as old, as near 40 years and still developing on it.

Game dev is quite different. We had tons of discussion on that. Even recently.

There are tons of games, with targeted short life span, for example available on steam. No need forever / continuous upgrade them. Is counter productive. +other topics we had, discussed pros and cons very well.

Either way, there is definitely no Right / Wrong way.

For OP, I believe porting to 2017 first, would be safer way.

 

The gaming industry. Buy yeah the financial sector used to be the same. But atleast here in the EU they have catched up. They still have some core systems on AS400 etc, but most new systems are on the .NET stack or Java. That bank was also very early on continuous integration, already back in early 2000 they had CI.

Pretty funny though you disagree with me first to end you post with that you agree with me that it should be done incremental (which is my entire point).

 

I have not agreed with you, since I accept option, of not requiring continuous improvement in certain cases.
However, you try to imply, your way is only good way. Which is wrong attitude in general.

 

I really, really think its a good idea have a branch with latest version yes so that you know what it takes to migrate. Everything else is guesses and thats something hobbyists are doing

 

The company itself is more about prototyping up to now and they have only one programmer currently working there (yours truly), I was asked to figure out if it was possible to update to a newer version and get on an LTS (Boss thinks LTS is a holy keyword, which I can now say isn't really the case reading these posts.)

To give the reason why we are updating to a newer version would be very difficult, my boss just asked me if it was possible, I said I would look into it and so I made this post. The reason we were still on 5.6 has a lot to do with the fact that the previous programmer (who wrote a lot of the code) is no longer working there and the project died out for a year or so IIRC. Boss wanted me to revive the project and possibly update it.

What I ended up doing was to update to 2017 first, and see if everything still worked, that went pretty well (save the few obsolete lines of code) and afterwards to 2018.3 which didn't have any issues. Nothing broke so I am now trying to figure out the mess I was left with since the project is barely mine.

I do understand that updating is never required, and in more cases than not causes more harm than good, but I found that some of my fellow workers (more specifically artists) want to work with shadergraph and as such 2018 would be quite interesting. I myself am also quite interested in creating my shaders and nodes this way and research taht part of the editor.

I have since talked this over with my boss and he has given me the OK to test updating, but once we have updated to this version we are not planning on updating to any versions other than the upcoming LTS (and its updates)

 

Guesses like the ones you're making about the costs of not updating?

You keep bringing this up over and over again, and never seem to be able to respond to details with details. May I please suggest that you start a thread with a fresh discussion on this to keep it all in one place, and then instead of posting the same stuff in thread after thread you can drop one nice little link and call it a day?

I think this is a perfectly sound plan. You mentioned that you've been in prototyping until now, that the project has had a staff change and a year of inactivity, and that there are specific new features you're interested in. With all of that in mind, I'd confidently say that now is a good time to update.

I would recommend doing this by getting the project working in the original version of the Editor first. Once you've checked that it all works, then start working on an update to the new Unity.

I trust that you're using a version control system, Git or something?

What platforms are you aiming at? Some platforms unfortunately do require updating from time to time. If you have 3rd party dependencies then that could have an impact, too.

 

Upgrading is usually needed for new features, but sometimes new versions are needed to get the latest bug fixes. For example, I recently went from 2018.2 to 2018.3 in a project, and it was done only because there was a crash bug in 2018.2 that was only patched in 2018.3 and 2019.1. The bug was never patched in the 2018.2 branch. I generally agree that it makes sense to avoid major version changes mid project, but there are times when a key bug fix might only exist in the newer branches.

 

If non game systems are worthy of credit here, I feel like I should chime in and say I work on systems where best practice is not to update for decades at a time. These are not small companies either, over the past decade I've worked with multiple multi billion dollar companies that take this approach.

Choosing when to update is a complex decision. Some factors that go into it include:

• The benefits of an update (new equipment, maintainability, increased reliability).
• The cost of the update (new code, training, new equipment, downtime)
• The risk of the update (new bugs, unproven technology)

My advice and experience based on these systems is to never update. Ever. If you are forced to update, do it once every fifty years or so. Update to software that's been battle tested for at least a decade. Never allow automatic software updates. And perhaps the most important rule, never let an enterprise developer near your process control.

Spoiler: Note

Obviously this post is a little tongue in cheek. Best practices that makes sense for running a process computer on a high risk chemical plant is essentially irrelevant to running a video game.

 

Well, the same principles apply to the decision making process. They just have radically different inputs, and thus end up with radically different results.

 

I have worked at a Swedish medical company with same level of risk analysis (If a medical software fails it could mean killing a patient) . They have adopted continuous deployment with a very high level of QA. Plus because of patient journal confidentiality each system is deployed locally on the hospital servers and machinery which means extra complexity versus own hosting.

 

Just to be clear again, we are still on 2017.4.x in production. But have both 2018.3 and 2019.1 in migration bracnhes that we are testing on. So its not like we push updates straight to production. They are very thoroughly tested first.

It seems many people do not understand that QA does not come not from not updating packages and frameworks. It comes from good test coverage, good test team, etc, etc

 

Who has equated those things?

 

Its very clear most think QA is thrown out the door once you go continuous and agile

 

[Citation needed]

 

I have thusfar made sure all code worked and ported it into 2018, which seems to not have made any real problems.

We are doing exactly this, we have a local hosted Git server thats taking care of all the data (but this is something fresh since it didnt exist prior to me being here, which is 12 weeks ago)

We're looking to build towards web and standalone windows and apple devices. Currently there are no third party dependencies that we would need to keep into account.

I should mention I do not work at a game company, but on a virtualisation project for a city. Though I hardly think it matters I should mention it in case I haven't yet.

 

In my experience it's not domain code that break. It's particles, substance materials and the like.
But, some domain code do break, for example in 2017 invariant culture was default but in 2018 client culture was default. Which broke a custom parsing we did

 

Depending on what devices, this may prompt you to update from time to time.

 

If it is required to do so, i would have to do it. (Not my choice on that front though)