So I see that Unity has released 2017.4 as a “Long Term Stability” release:
I had some questions!
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?
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.
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?
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.
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.
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.
No idea
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.
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.
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
We’ve got a blog post coming with more details shortly.
To answer one question specifically:
Yes. We’re going to support 2017.2 and older for 12 months each, like we already committed to, but by the end of this year that will all have finished, and if you want to get patches for a long time then the LTS releases are where you will need to be.
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.
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?
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!?
