Why have Unity 2017.4 if you have 2018.1? I’m currently using 2017.3.
Fixes for Unity 2017 for people who don’t want to potentially break their projects by going to 2018. Also Unity 2018 isn’t out yet.
–Eric
Unity 2017.4 (and future end of the year releases like it) is a long term support release and will receive two years of patches with no additional functionality. For some developers having a very stable engine is more important than having the latest and greatest features.
Unity 2018.1 is a normal release and will only receive support up to the next normal release. A few months at best.
Can 2018.1 break scripts from 2017.3 upon compiling?
As you said “potentially break their projects by going to 2018”, is this just relating to the new scriptable rendering pipeline? Or there are any other major changes in 2018 that will break the projects?
There’s a fairly massive list of changes (click the ‘Release Notes’ tab). Obviously we are not trying to break projects, but with so many things being touched we can’t guarantee that it will be butter-smooth for everyone - that’s just the nature of how making large-scale changes to a development platform works.
So, the point of the 2017.4 release line is to give you releases that don’t have the large-scale changes in - no new features, no refactorings, etc - just the most critical changes needed to unblock people from shipping.
Are there four releases each year? XXXX.1, XXXX.2, XXXX.3, and XXXX.4?
That’s the plan, with the .4 release always being the start of the LTS for that year.
Every new release has the potential to break existing projects. I had about a half dozen things I needed to fix in my project just going from 2017.2 to 2017.4. 2018.1 is going to be a much bigger leap than that, with a lot of new functionality and some older things being retired (legacy particle system and monodevelop off the top of my head).
I just upgraded from 2017.3.1 to 2017.4.1 nothing broke. So its relative safe