Unity 2017.4 and bugreports/-fixes

Hi everyone,

since we had this happen a few times recently, I wanted to bring it up here to see if there are others that feel something isnt quite right with the so called "long term support" of 2017.4.

So, we are currently working in 2017.4 and plan to ship our game with it, mainly due to the fact it is supposed to receive support for a while to come and the switch to 2018 would be too disruptive for our project at the moment. Which to our understanding is the intended use of the LTS releases.

Now, when we find bugs in 2017.4 and report them, we usually expect (more often 'need') them to be fixed for the version we are working in. But a recent reply in fogbugz was just

For another issue we got the reply that it would be fixed "for a future release", which turned out to be some 2018.2 beta. Only after explicitly asking for the backport and 2 months of waiting did it finally arrive in 2017.4 (without us being noticed that it would actually be backported at all).

I understand that for the Unity dev team 2017.4 is really old, most of them are probably working on 2018.3 features. Issues will be checked first against the newest version and fixed there if necessary, sure. But the main draw of an LTS stream should be that it does receive important fixes and not that you get told off after a bugreport to "just update".


Did anyone have similar experiences? What is your expectation when reporting an issue with 2017.4?
We are getting a bit annoyed by this, in the announcement of the TECH vs LTS streams, it sounded like such a great thing, but the reality has not been quite as expected.

 

I would expect that whether they would backport a fix to 2017.4 would depend on how much that system has changed between then and the latest/greatest.

For example, if you report an issue in 2017.4 that is already fixed in 2018.x, but it was fixed as a consequence of that system being significantly redesigned (possibly to tie into some other new feature exclusive to 2018.x), they are unlikely to backport those changes. They are also likely to view writing an entirely new fix for the issue just for 2017.4 as an inefficient use of their time, unless it is a critical bug or lots of people are hitting it.

 

I agree that an entirely custom fix for a redesigned feature would probably be too much work for usually little gain - IF a workaround exists.
The thing is... should the first responder of the QA team decide this? The first issue i described got immediately closed due to it being not reproduceable in 2018.x, but at that point nobody knows if a backport would be relatively easy or not, right?