Official Unity 2017.4 LTS is now available

I believe there's finally been some resources allocated to overhauling the whole Issue Tracker and making it all make more sense in a world with multiple release streams. I'll pass a note onto the relevant people.

 

Given that IL2CPP support for Windows and macOS was only added in 2018.1, I don't see how this bug can possibly affect the 2017 LTS line.

 

Could you give me the bug number? "trying to apply changes to a prefab" is not a very reliable way to look it up for you.

 

So the main issue is "how risky is this change?" Larger fixes are usually higher risk just because they're touching more code - though one-liners can be very risky too, depending on where that one line is. There are absolutely some changes that do not get backported because the risk is just too high, especially if the issue can be worked around. The most effective way to minimise risk from a change is to not accept that change.

It's important to note that as part of this, we do not backport fixes to LTS by default. Occasionally the developer making the fix will proactively backport it (usually because they already know that it's affecting customers in the LTS line), but in general we do not even begin to think about backporting a bug until someone has asked for it. As such, if you're filing a bug report and getting the response saying "This is fixed in 2018," and you want to see it in the LTS, please do respond to QA and ask if the issue could please be reviewed for a fix in the LTS branch. Explain how it affects your production so we have a better idea of why the risk is worth it.

The answer might still be "we reviewed it and it was too risky, sorry," but it also might not. (Sometimes the right thing to do is not to backport, but to come up with a different fix for the LTS branch).

This is not an ideal workflow, we are aware - improvements are hopefully coming.

 

You mean commenting on the public IssueTracker site? Unfortunately not - while we do sync the comments from the IssueTracker site through into our internal bug tracker, they don't cause a bug to be reopened - and it's not as simple as "just reopen the bug then," we have to establish a process for who to assign it to, how to reverify it, what to do if our repro case is fixed but people are still saying the bug exists, etc. The team responsible know that there's still work to do in this area.

It's not quite that simple. Neither branch is a guarantee that any specific bug will be fixed - we do not offer any guaranteed way to get a bug fixed, not even to our enterprise customers. We work on fixing bugs and we tackle what we can, but we can can't make ironclad promises about any specific bug, and even less can we do so for 'bugs in general.'

What we do offer is a choice about how much risk you want to be exposed to, by choosing how you want us to work: do you want us to be moving the technology forward (giving you new stuff, but with a higher risk that we break things that screw up your production), or do you want us to focus on fixing critical issues and otherwise minimising change (so you get many fewer fixes, but with a much lower risk to your project). I say low risk, not zero risk - as noted, we cannot offer anything that comes with a guarantee of no problems.

Does that clarify things? Effectively I'm saying: it's always a gamble, but it does not have balanced odds.

 

We're not planning on a separate system, but yes, we do recognise the need for users to be able to express "this issue affects me and I'd like the fix in the LTS please" through a better system than emailing us and asking.