Unity LTS version questions

So I see that Unity has released 2017.4 as a "Long Term Stability" release:
https://unity3d.com/unity/qa/lts-releases

I had some questions!

1) It seems like this should be the recommended default version, but instead it's hidden away and the default is still 2017.3. There wasn't even an announcement anywhere about this, which seems odd. I would think if this is legitimately supposed to be the "most stable" build, you'd want people using it ASAP. No?

2) One of the most annoying things about submitting bugs to Unity is getting back an email that says "can you test this in the latest beta version", because I don't have the time or patience to keep installing the newest beta every week and test every bug in all of them, that is what you pay your testers for. It's super annoying to go through all the trouble of submitting a full repro project with a list of steps, and then to have someone not even look at it and instead just ask if it works in the latest beta, and then close it a week later due to lack of response. SOOO... can we get some kind of guarantee that for an "LTS" version, if we go through all the trouble of making a repro project and submitting an example, that someone will at least actually look at it instead of immediately asking to just try the latest beta to see if maybe it randomly got fixed? I would absolutely love to have a version that I knew I could submit bugs for and have a chance to have them looked at without needing to mess around with whatever is in the latest beta.

3) It says that LTS won't ever install "new features" which I agree with in general, but how are you going to determine what defines a "new feature"? If a feature is broken in 2017 but working better in 2018, like say, the .NET 4 update, do the fixes in 2018 count as a "new feature" or is that a fix for an existing feature?

4) You guys are currently juggling patch releases for like seven different versions, like 5.6, 2017.1, 2017.2, etc. Mostly because there are always severe breaking regression bugs in every new version, so devs are afraid to update. Will part of this LTS initiative be pushing devs towards the LTS rather than trying to juggle a bunch of versions at once? Can I suggest a strong yes? Having more people on one version means more focused bug reports and more stability. But the lack of announcement and the hidden page kind of make me doubt this is the intention. What IS the intention?

 

I think game engines need more constant updates then most software, but versioning should actually mean something other then 'there are changes'. Which is basically all we have now. Even LTS just saying no new features, means nothing to me really.

If you said no api changes/additions and no changes in behavior, that means something. It provides a very explicit context to work within that you can reason about. No behavior changes is always hard to guarantee, but strict rules around api changes make it far easier to achieve.

 

Sounds exiting! At the moment something like this LTS release is the only thing that would make me consider updating past 5.6.

Quote from the site: "Each LTS stream will be supported for a period of two years."
2 years after release or 2 years after the version number in the name? Because it looks like "LTS Release 2017.4.0f1" was release in 2018. That is kinda confusing.

 

I think that is something the LTS versions offer. I'd like that to be taken one step further so the YEAR.0 is the only one with API changes, the YEAR.1 to YEAR.3 versions could have additions, and the YEAR.4 being the polished LTS release of that cycle. I can plan around something like that with a fair bit of confidence.

 

Oh my goodness, I like the sound of that!

Honestly, one of the issue's I've had with Unity is the whole culture of "always update to the latest version". Even when I went to Unite some presenters were having issues precisely because they had updated to a newer version than their stuff was tested with.

I think that some of your questions are broadly answered by the blurb on the page you linked, but there are edge cases in the details you raised that are definitely worth asking about.

Generally, it sounds to me like it's purely about stability and shippability, which I think is a great option to have.

 

1) I've had the same question as well. The only announcement I've seen was spoken at the GDC keynote, and they even got the version number wrong. I haven't seen anything in writing other than your link. There's no mention of 2017.4 anywhere else that I can tell. (I've been using 2017.4 for a week, and am generally happy with it by the way)

As far as I understand, 2017.4 is now effectively the 2017.3.1 patch release branch. If that is really the case, Unity should tell users of 2017.3.1 that they will not get any new patch releases for that version number and to move to 2017.4, otherwise they may continue thinking 2017.3.1p3 is the latest patch for their version. If they will continue to release 2017.3.1 patch builds, I'd like Unity to say what is any different in those than 2017.4. So far there has just been silence on this topic, which seems a bit strange for such a change in how Unity is going to support their software going forward.

2) No idea

3) Unity has already an established precedent that they don't backport changes for features to previous builds where in those older builds the feature was "experimental". They also are not going to backport anything that changes an API. I expect them to take everything else on a case by case basis.

4) I think Unity primarily wants its users to move to new software as soon as possible to stay on the new feature hype train, and to help report on issues found quickly. I think the LTS version is in response to a growing opinion that new Unity releases are half baked and full of bugs that should have never been released (I think this is more due to the increasing complexity of the engine, and not a decreasing quality of their QA process, but the result is the same either way).

Now Unity can say to those people to stop complaining because you have your own special version with a year of development and fixes behind it and an additional 2 years of patch releases for it.

 

Maybe, but I hope not.

It's pretty normal for large teams to stick to particular versions of software for as long as possible because once you've got your systems established you want to minimise changes. LTS builds aren't unique to Unity, and other places they're used (eg: Linux distros) don't do it because it's otherwise half baked or buggy - it's just to target different use cases. For short projects or low-risk usage or where new features are desired, go for the latest release and update regularly. For long projects or where unnecessary change is undesirable, LTS builds are great because they mean you get stability but you still get support.

And, as already raised, by nominating specific LTS branches you can provide that long term support without spreading yourself thin over a broader range of branches. Users should get a clear message that if they want long term support there's a branch for that, otherwise they're expected to manage the upkeep of the constant updates.

 

I agree that's usually why devs release stable builds separate from a dev branch, but in Unity's case they do have a reputation for breaking things that were formerly fine and introducing bizarre new bugs in every point release. Most apps would have one main version called, say, 2017, and you would have one "stable" branch of that and one "in development" branch. Instead, there are now multiple separate versions of 2017.1, 2017.2, 2017.3, and now 2017.4, all being supported as theoretically "stable" at the same time with a stream of new patch releases each week for all of them, with fixes in .1 not making it into .3 and vice versa, and rather large incompatibilities and breaking changes between them that are almost entirely because of bugs, not because of API or functionality changes. Sorry, I think I just switched into rant mode... I just want a stable build

 

Perhaps the release schedule is a bit tight, which stressing the whole production line. Even testers have figured problems, it might be too late to rebuild everything near the deadline.

Have some sympathy, people would understand it's not the only fault from the support.
They are receiving so many tickets a day, and number of them are not in well format, not mentioning submitting full project, some submits may also not able to isolate the exact bug, which increases lot of manual work before debugging.

 

This.. since i'm actually on 5.6

 

I noticed there aren't anymore patch releases for 2017.3 but instead there is already a new 2017.4.1 LTS. Eh?!
So are we supposed to look into the LTS releases now for the latest non beta Unity?

 

@superpig
Can you please add a RSS feed for LTS, something similar to Patch Release page


Thanks!

 

Is it recommended to upgrade to 2017.4 if you are on 2017.3.1? Lots of XR things in the changelog and we are a VR game

 

Came here to ask a bunch of questions, but the blog post cleared them all up! Thanks for posting.

 

Can you sort out the mis-matched availability of 2017.4?
The link for existing users is to 2017.3 (also the Update check) but new users clicking to download for first time get 2017.4.

It is like new users get to bug test 2017.4 while existing users await the result!?

 

https://unity3d.com/get-unity/download redirects to versions which has another download link to https://unity3d.com/get-unity/update

 

So I'm feeling that the people in charge of LTS and the people in charge of updating Unity are two separate teams. For the LTS folks, here are the things you need to still do:

1) Update the download page to point to 2017.4 https://unity3d.com/get-unity/update
2) Change the Documentation link to point to 2017.4 https://docs.unity3d.com/Manual/index.html
3) Change the Scripting API link to point to 2017.4 https://docs.unity3d.com/ScriptReference/index.html
4) Update "What's New" to point to 2017.4 https://unity3d.com/unity/whats-new/
5) Update the "Current Version" subheader on the forum to say 2017.4; it still says 2017.3
6) Make an actual Announcement post in Announcements
7) Someone tell poor old P-Jawahar and Davidlovegrove in the patch thread about how 2017.4 is taking over the 2017.3 patch cycle and have them update that thread with links to 2017.4
8) Add the ability to submit Asset Store packages for 2017.4 (not sure if this is done)
9) Update whatever needs to be done so that you can see 2017.4 in the Unity editor "Check For Updates" menu... I know you guys usually wait a month or two to update that link so that early adopters can test bugs first but if you're serious about wanting people to switch to LTS I'd say do that sooner rather than later.

There's probably some other places, but those are all the main places people look for updates and right now all of them still point to 2017.3.

 

In theory that shouldn't even be a consideration here, because this is just a rename of an existing, known stable branch that's had months of active production use... right?

 

oh dear, new users [in particular] must be so confused right now!

 

So the online User Manual is now for 2017.4 but on front page it says:

• Features introduced in 2017.3: What’s New in 2017.3

 

see:

 

Well fair point point though it could reiterate to avoid confusion and that page then links to release notes and fixes/improvements for 2017.3, but presumably a 2017.4 release may have further fixes/improvements

 

Indeed, I'd have thought that the "whats new" page would be replaced with something that explains that there's deliberately nothing new, and - since it's the whole point - explains what is supported and until when.

Edit: Beaten!

 

All in one: http://rss.uphero.com/rss/rss.php
LTS: https://unity3d.com/unity/lts-releases.xml
Final: https://unity3d.com/unity/releases.xml
Beta: https://unity3d.com/unity/beta/latest.xml
Patch: https://unity3d.com/unity/qa/patch-releases/latest.xml

 

Very useful, Thank you very much

 

I thought I understood what LTS meant, but then I read this in the last 2017.4.5f1 LTS :

• iOS: Disabled builtin cache in iOS UnityWebRequest backend for consistency with other platforms.

I find this strange because behavioural changes can potentially transform UX.
We could say the same thing about a bug fix but in this case it's a voluntary change.

 

I believe they did consider it a bug, and that it was unintended and undocumented behavior.

https://forum.unity.com/threads/unitywebrequest-keeps-caching.519489/

 

I would like to know why I have to download a whole new package just to go from 2017.4.4 to 2017.4.5? If these are just bug fixes and minor changes, there is no reason for an entirely new install.

 

With the package manager letting us take a peek at built-in packages, it seems obvious UT are planning to extract them into real packages over time. At some point the editor itself will barely need updates, and it's all individual packages for the features you actually use.