Feedback The State of Unity & Packages in 2020

So, I took a 2 month break from Unity because it was so unstable; and, almost every package I used broke or had serious bugs. I now return and within 10 minutes of using Unity it crashes. You are failing on one of the most important metrics of a tool that people want to use on a daily basis - stability. Enough new features, etc. - focus on stability and quality. You are making the rookie mistake of every early-stage company of trying to be everything to everyone and failing to provide a tool that is useable by anyone.

 

Im over the moon that you are engaging us about this . Been a big issue for a while now and glad to see its being noticed by the product management team. I know @willgoldstone and some others from unity have been active in this regard and it always is greatly appreciated.

I know it sucks to hear lots of criticism but trust me when I say its really good that your engaging us and I hope it continues! Hopefully the feedback we provide will be of some use to you guys to get unity back to where it should be (the best free and commercially available game engine on the planet)

EDIT: forgot to actually answer the questions, they are below:

Some core product questions we would like feedback on:

1. What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?

Right now it doesnt really mean a lot. My understanding was it was meant to be 3 tech releases and 1 stable supported release, problem is due to constant changes 2019.4 is mostly useless as a lot of core needed stuff is coming in 2020 cycle, so if you want stable you have to jump to a tech release. Making all of this pointless. This is due to certain packages requiring certain versions of unity, meaning you choose between feature support or stable editor. Sometimes you choose between editor stability or feature stability. Not a fun juggling act. Less so when doing it at work where there are deadlines and real repurcussions.

1. When you see a new Unity release, what is your expectation of quality?

Its actually very low. It used to be higher. When we first heard about alpha opening up I was over the moon as I thought the early exposure would mean better QA that takes place over a longer period of time. It actually seems that all that is happening is you are rushing releases out earlier now and shoehorning needed features into later releases with a lot more frequency.

1. Do you expect different levels of quality or completeness based on the release distinction?

Yes. I expect alpha to be feature complete, beta to be content complete (user interfaces, usability,documentation on new features), and released version to be stable. That is a world away from where we are, is it not?

1. What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?

Again stability, which doesnt really exist anymore. I believe doing only 2 tech releases will help somewhat but not fix the problems altogether.

And more package specific questions we would like feedback on:

1. When we say something is in Preview, what does that mean to you? Why do you feel that way?

It means it is an early access version and bugs should be expected. I would not expect design and architecture to change dramatically otherwise it isnt ready to preview. In that case make a seperate distinction between "alpha preview" and "beta preview" or just do alpha and beta and released for packages as preview seems weird - your software developers....

1. Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?

My expectation whether in preview or not is to expect serious stability issues, incompatability issues, usability issues and performance issues. Didnt used to be that way but slowly over last 6 months I have reached this point.


EDIT2: PS, despite the criticism dont take me as a negative user. I love unity and always will, but being honest about where we stand is the best approach IMO. Everything I write as feedback, I do so in hopes to help make the engine better, not because I enjoy whining (which I really dont)

 

I won't be answering all the questions because I very much agree with @GameDevCouple_I so i will focus on what I personally feel the most.

I want to emphasize that due to package requirements as well as QoL and workflow improvements requiring the latest version, it feels useless to stick to LTS. Some times things are needed for a certain aspect of the engine to work properly, that are not strictly considered bug and thus they don't land in LTS. With packages this is worse, as sometimes actual bug fixes land in new package versions that depend in new engine versions.

In it's current state I think is very difficult to make a sensible estimate as so many features, and therefore potential instabilities come from packages. Normally I don't expect a major version to be consistently stable until 2 or 3 patches. i.e: 20XX.0f1 is usually closer to beta than to final release.

No. If anything I think in some cases the focus on stability of LTS versions has brought problems: The release schedule of new features, combined with the strict policy of only backporting bugfixes results in cases where a feature is half-baked for 2 years for those sticking to LTS. Most clear example being the new prefabs introduced in 2018.3.

 

If I download 2019.1 and its unstable I think well okay thats not the LTS version. If an LTS is unstable, it makes me want to flip tables and scream at someone because we often wait an entire year (somtimes longer) for the "stable" version and thats exactly what it should be. To be honest however, if each .x release has an alpha, beta and release phase, it doesnt make sense that anything other than extra tech should be unstable by time of release. Which again, highlights how the current release structure doesnt give anywhere near enough breathing room for the teams to provide the quality expected. I would do 1 tech release, 1 stable release. So you save up all the tech and release that as 2020.1 and then work through the year making it stable to do 2020 LTS.

The package system should make this much more feasible now as you can roll out new features seperate from the editor features etc. But if we are doing packages, what is the point of tech releases anyway? isnt all tech packages at this point?

 

Gaia Pro, Terra World, and almost any program with modified shaders. And, almost anything I use with the HDR pipeline is a disaster.

I am currently using 2019.3.3f1. When I was having troubles earlier, it was with earlier version of 2019. However, today with Gaia Pro and 2019.3.3f1, I generated a terrain and then it crashed.

I assume by 2019.4 LTS you mean 2018.4 LTS. I used the LTS versions when I teach; however, using even the stable versions with the 3D game you had with Ellen was a mess. A lot of your tutorials/template games you put out are not kept up to date, so most of them become quickly useless as others have mentioned above - features/functionality don't match.

Finally, I am trying to sort through my assets in the editor asset store and it keeps jumping to the top - obviously some sort of bug.

 

@smcclelland

1. Interesting point regarding the juggling of feature stability vs editor stability. Is this something you've noticed has increased with our inclusion of packages?
Yes, its solely happened since packages have come out. And again, its not all of them, just some are super unstable and dont gel good with the current editor version.

2. That's unfortunate to hear. Was your expectation around the alpha that you would have access to things earlier in development and help drive things over a longer period of time? If you see something in Alpha that's not ready or moving in the right direction, how would you want us to handle that?
I mean I just expected that by the time it releases there will be docs and serious testing involved. What happens during alpha isnt the main issue, its what doesnt happen during beta and release. Beta should be when all the docs are being made which in turn will highlight usability issues and in turn will lower user pain which in turn will lead to no need for this sort of conversation to take place in the first place.

3. To be honest, yes. In what sense would you want Alpha to be 'feature complete'? For example if we gave you a new brush-based terrain system would you expect that to be completely done when it shows up in the first Alpha? Have some missing functionality that's added over time? And what about Beta? Mostly bug fixes? Any API changes?
I expect alpha to contain all the new features that are meant to come out, but they may be buggy and unusable (like the UI for the feature may not make sense or stop it being used well) and be undocumented. I would expect beta to be bug fixes and building the usability (including a new UI if needed, creating docs and releasing these to public so they can comment and say "that makes no sense, I dont get how to use X" or "That shouldnt be used that way, would be better this way" and then make those ammendments if needed. I would expect public release to have contained all the above so that its usable from day one with proper docs and stability (as much as possible, not expecting miracles I understand how commercial software works - nothing is ever bug free!)

P1. Interesting. So if you saw a 0.5.0-preview you would expect some bugs and no major changes to happen until what point? Would you expect additional functionality in a 0.6.0-preview? What about if you were using a 1.0.0-preview? Does the version number have any significance or meaning to you as a user for what's included in the package or different between versions?

No I would still expect changes, but I mean for instance if a system has been built to be say LWRP, I dont expect the entire architecture to change after its gone into preview (turning into URP - just one example ofcourse - lots of this all over the place). That shows serious lack of foresight on the design part. Again, early docs would highlight this as users would tell you their pain earlier if they knew how to use the system. The version number means nothing really, but when a flashy blog post comes out saying something is in preview, it shouldnt have massive fundamental changes (features added or removed or completely changed) after that point unless its literally do or die. Once people read that stuff they get excited and make plans based on it, so big breaking changes and u-turns on design decisions will affect them and create user pain - even if justified.

P2. That's fair. So even if we say a package is Preview, Verified or Released, there's still a lingering concern of stability, incompatibility, and usability issues? Yes absolutely, but I do believe that the user engagement on your part (you and rest of unity team) and the new release structure proposed will help somewhat.

 

I actually dont think LTS makes sense at all. As in I dont think you should declare which version is long term supported ahead of time, that is causing a problem where major stability problems seem to get pushed back as "theres a stability focused release coming" but because the stability focused release is at the end of the cycle, its never actually stable as there is no time for the team to ensure 3 releases worth of stuff becomes stable in like 3-6 months time.

I would just make unity releases without the LTS moniker, and at the end of the release cycle pick the latest greatest to become LTS and continue to support that for 2 years. I also didnt know LTS and tech have different standards, it feels like they are the same right now?

I think the idea was understood but it doesnt really feel that way in practise. It feels like instead of worrying about upgrading a single program, we have to worry about upgrading it AND various packages and it creates a compatability depedency spaghetti that is hard to debug at times.

I think this is probably making it harder for unity QA to determine things too. I havent heard of anyone not being stuck having to update at some point or another the last year. Before I could remain on an old but stable version for as long as needed, but due to features in packages - I now often am forced to update due to a package I started using months ago now needing it to remain compatible.

The SRP and shadergraph packages are the biggest culprits in this regard. I am pretty sure that a massive portion of user pain comes from those alone.

 

"I would just make unity releases without the LTS moniker, and at the end of the release cycle pick the latest greatest to become LTS and continue to support that for 2 years."

^^ This nails it. And, make all of the packages be stable on the current LTS or they are marked deprecated. That way I can quickly set up projects and do what we all love, which is - creating games. Otherwise, I am constantly being a beta-tester for all kinds of other people's projects, including the Unity game engine.

 

With packages I tend to be more flexible, because I can downgrade a feature if it's bringing me trouble and I don't have to wight in losing completely unrelated features. I normally look into the package docs and watch the forums closely, that usually gives me a sense of what i could call "inertia". That being, is this package advancing toward where I need it to be, or is it pretty much stalled?
Good examples of this are the input system and quick search. The level of interaction and willingness to assess feedback is reassuring.

Also, I agree that the preview label is not enough. Having distinct branches with alpha/beta/final tags, and having the same rules and expectations than with the engine would be ideal. The first public alpha should showcase the initial offering of the package, during alpha period there should be openness to add/change features, API and workflow, and during beta there should be focus in stability, docs and UX.

Hey. I've spent the last 15 minutes trying to answer this 2 questions, and realized I've been contradicting myself. I think the gist of the situation is that you're in an uncomfortable middle ground between being non-disruptive and moving forward. I think you should choose on or the other. Personally I would much prefer that you stopped releasing versions in a fixed schedule and gone back to releasing when you feel the tech is there. Make changes without fear of upgradability, don't linger on old stuff forever, and when you feel you have a well-rounded package, bump the major version and signal clearly that people wanting stability should stay behind until their project ends.I think it's preferable to have a big jump every 1 or 2 years that it is to be in a constant state of flux. But of course that's only my point of view.

I'm sorry if this is not the answer you were expecting but I've realized it's very difficult to put some sensations in coherent words.

 

From https://forum.unity.com/threads/unity-2019-3-is-now-available.817029/page-5

Exactly. Nailed it. For smaller projects – and there's nothing wrong with them – the pain isn't quite as noticeable. However, if you try a larger project you will quickly run into problems. There is then the added problem that different types of developers get very different impressions of the state of Unity depending on their experience and background and thus have trouble communicating with devs with other types of experience and background.

The problem with Unity is that there's never been a really stable release, not even an LTS one. This forces people to upgrade to tech releases in the hope that a crucial bug finally might have been fixed. This is especially so if your project pushes the engine or the editor in any way.

I think it's important to view features promised to us, and features given to us in a first implementation, purely as marketing rather than tech. All these promises are there to keep us hooked. Same thing goes for all the demos: they represent not the state of the engine available to all devs at the time the demo was made, but an idea of what Unity might become. Fine, you can create something similar to the forest in The Book of the Dead if you work really hard, but it won't be an area large enough for gameplay. Also, the official demo you took as inspiration probably only will work for the specific version it was written in. Even minor version upgrades breaks the demos most of the time. Thus, they are marketing ploys directed towards subscribers in order to keep us hooked.

The problem for me, who have been using the engine since 2010, is that all those promises made during a full decade never have been delivered upon fully. "Oh, yes, multi-terrain handling is coming soon," "There will be a new multiplayer networking layer really soon," "The new GI system will be fantastic," etc, etc, ad nauseam. I've waited for 10 years for Unity to create something which is usable for my type of game. I've finally come to the conclusion that it will take several years for Unity to stabilise even if they manage to add all those features which they've promised us for many years now. I can't wait that long. Thus I'm simply using the wrong engine and need to change. Consequently, I have downgraded my subscription from Pro to Plus and now Free. Why pay for being an alpha tester for something which claims to be a colossus but still has clay legs?

On the other hand, if Unity works for someone, all power to them. The whole thing boils down to choosing the right engine for your type of game. However, the sad bit is that Unity has misled us all as to the current state and plans for their engine, so that choice has been very difficult to make due to all the ... ahem, "fake news" we've seen over the years.

 

Imagine if every Jetbrain release broke every package and people's workflow or if everytime Apple released a product it would not work with any of the prior applications - I would stop using them. Similar to this person, there is no way I will continue to pay for a subscription. I expect my tools to be Jetbrains/Apple solid. I got things I need to get done.

 

For Rider - it is early release vs. product. I don't mess with early-releases on other tools. Only with Unity because some packages are compatible with this release or that release and another package may not be compatible - way too complex. A package I am using now required me to load a patch to work on 2019.3 and then had a link to go the experimental play mode option - just to get things to work. Heaven forbid I add another package to this project.

 

I think alpha/beta/release would cover it better. And instead of a "verified" label, treating the editor version as just another dependency would be much more consistent. If, let's say, Entities 1.2.0 package depends on Math 1.4+ and Editor 2019.2+, I immediately know what to expect.

I would answer the same I said before for packages. Initial public alpha that shows the offering as devised by the devs, alpha period for users to steer the development with their feedback, then beta period focused on stability/performance/UX/usability/docs.

Make clear what the goals are for each pre-release version you give to the users. What are the devs focusing on? What feedback do you expect at this point in time? What issues should be taken care of before moving on to the next phase?

I wanted to thank you for opening this kind of channel. It's the kind of transparent communication I would love to see in general.

 

I really appreciate having a candid conversation with users about the current state of Unity. That said it's tough when different people are doing different things with the engine, so I'll start with context as to what I am doing and give me feedback.

I run a small studio and work on small to mid sized games. We work on our own internal projects as well as co-development with other studios. This is often tools, optimization, and, most often, porting services to mobile and console. Every so often we will also handle all the development of a client project though we have moved away from that type of service, generally.

We don't tie too heavily into third party tech: much of what we build uses features of Unity but a lot is also in house code/tools that we've built over the past six or so years.

I've split the questions into two sections: core Unity and packages.

Core Unity​

I have a different view from some of the people who have already posted but I'll keep it brief. The point of tech is to bring the latest features out and LTS exists so that you can support your game near and post launch on various platforms where you must release on the latest SDK (iOS, consoles).

I do not view LTS as the stable branch and Tech as the less stable option. Ideally, they are both stable (though tech is less so due to the nature of getting fresh releases). LTS is specifically so I can update my game and know that it will be allowed on the platform by the platform holder.

In a perfect world, everything would be stable. I understand that between tech releases there may be API changes to allow for new features or a different workflow than originally planned, but it should all work. For the most part, this has been happening (talking purely about the core engine and not packages). I haven't had any of the crashes that others mention but I also keep our internal projects quite clean and optimized for the editor. Client projects can be less optimized (I get quite a few editor stalls in some of them) but no crashes.

To a certain degree, yes. I would assume that LTS is getting much more thorough testing as a regression could be disastrous for a project close to submission. The last thing I want is to have to update to a new revision of an LTS release to be able to port a game and then have that revision have some issue that can't be solved. I'm often updating client projects from a non-LTS to LTS branch to prep for release so I expect issues in those cases. But once the move to LTS has happened I'm of the mind that future updates to that release should be 100% painless and working.

In practice, I usually move to the LTS branch, find an SDK version that won't be deprecated before launch, and then avoid updates unless I absolutely have to.

Continues platform support without having to worry about an update breaking our project. If I'm close to launch(six months to a year), we will jump to LTS so that the team can be certain that we won't need to update to a minor/major release of Unity again, regardless of SDK updates from target platforms.

Packages​

To start, I want to say I love the package manager. Decoupling non-essential feature updates from engine updates is a very smart move. Allowing users to tie their own packages into the package manager is a very appreciated bonus. The ability to constantly deliver updates for a feature set is wonderful but it also introduces issues.

When a package is dependent on some part of the engine and forces an update to have access to it, it's no different from the old update cycle of Unity: wait for a new release. That rapid release cycle becomes hindered and the ability to quickly push out hot fixes goes away.

I have some issues with how third party packages are treated but I feel like that may be separate from the conversation here so I will keep those to myself for now.

Stable enough to learn and play with, but not to ship. Preview to me, which has been echoes before, means that the API is basically in beta. It's not going to change drastically and is, to the best of Unity's ability, working as intended. If anything is missing, it is fully missing. What I mean is that if a feature isn't complete or has some known issues, it shouldn't be in the preview until it is done and tested.

In practice, I normally mess around with a preview package but don't invest heavily into learning the API, let alone integrating them into a project, because they always seem to be released way too early. The APIs can change or the feature sure is incomplete or there are just bugs. It's just too risky to bring into a project. Being a professional and not a hobbyist, I often don't have time to just "play around" with preview packages when I have real projects to get done.

Packages have absolutely terrible documentation and API pages. Nothing should be getting released until documentation is written, reviewed, and edited. And that documentation should be on an official, Unity style API page, not a shared document.

Packages clearly aren't held to the same standards as what is included in the core engine and that needs to change.

I'll only download a preview package if it's something that's really going to add value to my workflow. The only packages I have ever downloaded in preview have been

• The new Input system as I currently rely on third party assets (InControl, mainly) for controller support. A built in input system that meets the standard set by existing assets from the store would be amazing, if for nothing more than needing the jump through hoops with third party providers when dealing with NDA'd platforms.
• Scriptable render pipelines for the sake of experimenting with a lightweight deferred renderer for lower end platforms, namely the Switch. This has been abandoned for the time being but I spent quite a bit of effort learning the API so that, at the very least, I would have the knowledge needed to edit the provided pipelines for optimization purposes.

Everything else, even when I think it might add a nice tool to our workflow, I usually ignore until I have to use it or it's out of preview and the general consensus is that it's a good tool to use.

 

TECH releases are somewhat bleeding edge versions, from which I expect new features, and more bugs than an LTS release. If you can wait for the features, you should hold out for the LTS version for improved stability.

I fully expect it to be buggy compared to earlier tech releases, and very buggy compared to LTS releases. I don't bother moving to a new TECH release until it's had a few patch releases to fix major issues. With 2019.2, I remember holding off a full two months until the HDRP team finally fixed a one-liner null reference exception that was holding me back from upgrading.

In that LTS is essentially the last TECH release plus a bunch of big fixes, I expect LTS to be more stable than a TECH release, if only because of the time it has had to shake out issues.

Historically, I've used TECH releases within a week or two of them becoming available. Starting around 2019.1, though, I've been very wary of the stability and completeness of the TECH releases. It's frustrating to see bugs in the "Known Issues" section of the patch notes for 2019.3 remain there week after week.

I don't think much about it. It seems like most of the packages I've been using have had a "preview" label on them. Mainly, I understand that it means things can change down the road that will require me to rework some of my code. But in general, the "preview" label hasn't (for me, at least) meant that a package is very unstable.

Again, I don't think much of it. I would be hesitant about building a whole API around some preview package, but as a general consumer of a package, I don't think the preview label matters too much to me.


Final Thoughts:

Two TECH releases per year seems fine. I'm with most of the above in desiring performance and stability of the interface more than most else right now.

I'm disappointed in the way some packages are simply pinned to major Unity releases. HDRP, for example, get a new version with each Unity engine release. That's not at all how I expected the package system to work. It's especially bad when it's not feasible for me to update to a new Unity version for some reason. It means I won't see any more improvements to the package. The total fiasco around 2019.3 being both the first Unity version in which HDRP is "Verified", and the last Unity version in which Realtime GI is supported in HDRP is a slap in the face that has been addressed elsewhere. My project will be stuck on 2019.3/4 for the foreseeable future, while the HDRP 7.X package stagnates, as development has shifted to HDRP 8 on Unity 2020. So, it's frustrating that HDRP 7 feels like a deadend.

 

Unity should really pay more attention to LTS releases. This bug was reported on October 16. Still not fixed on LTS branch almost 5 month later. Not even "In Review" state. Thank's god we found some wacky workarounds. And that is 2018.4. I can't even image how 2017.4 users are forgotten.

 

1. What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?

My understanding is that the non LTS releases are for the bold of heart, willing to help Unity as unpaid QA staff on their core engine. I expect that each and every minor or patch update outside LTS contains a possibly breaking change to my existing codebase.

I expect that LTS minor updates not carry a high risk of breaking existing code. More importantly I expect that every supported LTS will always allow me to publish to every platform offered during the editor's support lifetime.

I also expect that in an ideal world, bugs discovered in LTS be quickly resolved in the LTS release ahead of features in the tech releases.

1. When you see a new Unity release, what is your expectation of quality?

Minimal expectations of quality for any release that isn't an LTS. I find them to be high risk, especially in 2019.

1. Do you expect different levels of quality or completeness based on the release distinction?

I expect that all features included in a .0 or .1 release to be usable if not complete, with the provision that any new feature is used at your own risk. By LTS it should be sufficiently complete as to be usable with the confidence that Unity will in fact actually support it.

1. What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?

Stability and a guarantee that the editor will be able to publish to all platforms that are supported.

1. When we say something is in Preview, what does that mean to you? Why do you feel that way?

It means that it we use it at our own risk, and that we acknowledge that we are unpaid QA for the feature.

That said, it also means that we as users have a direct effect on the active development of the feature. This to me is a good thing.

1. Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?

I expect that it may have serious usability issues and bugs that could prove to be showstoppers, and which may or may not be addressed in a timely manner.


Other thoughts:

I LOVE the package manager for its ability to allow us to reasonably and sensibly share our own code and 3rd party code amongst out own projects. It has been an absolute game changer in workflow for the better. Simply amazing. It is one of my favorite innovations just for how much improved this is from how we had to manage code in the past.

However I have to echo others sentiments when it comes to how Unity uses it's own package manager to distribute code to its customers. Packages should either:

• Support all officially supported Unity releases back to the oldest LTS
• Not be available for installation on unsupported Unity versions at all.

Also it should not be released without adequate documentation.

 

I'm generally okay with working with TECH releases. I take stability issues more or less in stride. I will say that my attitude towards stability is probably strongly related to the fact that I have a "Save on entering Play Mode" editor tool running, otherwise I'd probably have lost it long ago. Sure, people don't like crashes that cause Unity to have to restart, but they sure hate crashes that cause them to lose work. Any reason Unity doesn't have that as an option natively. The majority of the crashes I experience are on entering play mode.

I generally hope for Known Issues to get some attention within another couple of patch releases after appearing in the notes. I realize that's not always the possible. But it was a full two months after 2019.2 was released that one of the known issues at release was fixed, at which point I was able to upgrade my project to 2019.2.

I don't think I've noticed any real difference between preview and verified. Mainly, as I said, I think of it as whether the API will contain future breaking changes, and I don't really think of it as a question of the package's quality. It doesn't seem to me that "preview" packages are full of bugs that suddenly get resolved for the verified release. It seems like steady march towards functionality and reliability that finally concludes at release.

In an ideal world, I would hope that HDRP features would continue to be added to some 2019.3-compatible stream of HDRP. It's not at all clear to me what future features in HDRP will be dependent on new engine functionality that doesn't yet exist in 2019.3. However, I assume that a fair number of features aren't in HDRP 7 not because of missing engine support, but just because those features haven't been prioritized yet. For example, I had hoped that by this point, we'd have full support for UI shaders in screen-space canvases. That didn't make it into 2019.3. I don't know if that's waiting on any new engine features, but I'd assume it's more of a priority thing. Assuming it's just about prioritization, I assume those features will never make it onto a 7.X HDRP branch, even if 2019.3 would support it. That's the disappointing part. I understand that backporting things dramatically increases the complexity of the package. But it's unfortunate if every new feature is exclusively implemented only as part of the upcoming alpha's development cycle.

 

Tech is Beta, LTS is usable (at least a few releases in LTS). But in the end it's pointless, since the bug I find in LTS will probably get fixed in a non LTS version (I'm sure there are valid reasons, but...) making LTS pointless.

My expectation for a new Tech version is that it's broken in obvious ways and all introduced features are barely usable.

Since after every LTS you basically "reset" on stability my expectation is that every Tech is a beta that can't be used, and LTS is "fine". Since you keep resetting the cycle every year, I can't see you ever releasing anything that will be considered good. (especially since certain bug fixes are dubbed "features" and are never ported back to LTS).

I don't know how feasible it is, but I wish you could have gone with some model, where over time, there is an overall improvement to Unity (with ups and downs of course), and we didn't have to go back to square one every year.

Right now what happens I constantly have to make the choice between staying on 2018.4 and have our game not crash all the time on Android vs being able to bake light probes that don't look like ass, thanks to features and bug fixes that only landed on 2019.3, but having to sacrifice everything else for that (editor stability, built game stability, performance).

Whether I want to work or fool around.

It means it either:
-Doesn't work at all.
-It has been deprecated/abandoned, you just haven't announced it.
-Might not be there tomorrow.

I don't consider preview and early releases to be that different. I still expect:
-It might not work at all.
-It might be abandoned (you have a history of releases undercooked features and then doing nothing with them until you replace them).
-Might not be there tomorrow because. Liberally paraphrasing: "We heard your feedback that feature X (which we've been working on for 4 years) totally sucks so to fix that we will spend another 4 years to make a similar feature that will also suck but in new ways!".
-I should not any installed because they will be used as excuses for lack of stability. Liberally paraphrasing: "The editor is crashing? Oh wait, you use a PREVIEW package, you should be expecting crashes then"

 

If you ask people what they want, they will say "faster horses" and they would right 100% of the time.

But let's take a step back and look at the bigger picture: unity communicates and present all versions with the same level of focus. A new incremental version comes out, a big blog post boast about all the new cool toys you could play with, and you download all of them on the same place. Practically they are indistinct and functionally they are too. That mean that whatever responsibility they supposed to have bleed into each other. Worse is that people not privy of the lore of the community and don't read blog, just assume the last versions is just the best, tech and lts don't stand out. That's a communication problem.

Contrast to how other software are presented often with faster and more broken experimental released, as fast as nightly build. They have a clear separation of concern, bug incremental number are meaningful and first class, they have the bombastic blog full of features, with day one documentation, a download section that emphasize the last version and a secondary call to action for older release and tertiary separate one, for experimental. The last version is guaranteed to be complete, and stable, and it create in the community an atmosphere of town fest. Experimental features do have their blog post, but the tone and presentation are distinct, they have the theme of exploration contrasting the various question arising from the journey and how the team is fighting around to discover the new features we will soon be able to play with, ie creating anticipation without actually announcing anything.

This sense of adventure use to be in old unity post, Aras blog was pretty much like that, in his epic quest to kill shader, up to conceptualizing surfaces, it was aspirational without making would be unkept promise. We add a sense of the challenge he faced and the solution only made then practical sense, engaging into a discussion, without having to unveil a silver bullet to be criticized after the fact, ie it prevented unnecessary expectations.

So while i haven't took the time to verify jetbrain's alpha vs released, when the answer was "i don't mess with jet's alpha", I'm sure the communication between the two states is much stronger than unity's.

 

The Tech releases are hastily relabeled Beta releases. They are notoriously unstable for almost all of my projects and I'm not sure I can even trust the LTS release of 2019 given how bad 2019.3 has been so far.

Were they any lower at this point, I could use them to tap into geothermal energy and power my apartment. I only touch YEAR.2.X releases if absolutely necessary, but for the time being I am sticking with 2018.4 with a branch on the latest version of 2019.2 for testing purposes and maintaining compatibility for internal tools.

I feel that this is answered by my last two responses.

Stability, both in terms of stability in the engine and stability in the API itself.

It means it's a fun toy I can mess about with, but won't be ready for use in production for at least two years. I feel this way because of the absolute state SRP/LWRP/HDRP/URP have been in for the last year, the new input system being extremely similar, same with UIElements (why isn't there a simple grid system STILL?)

As stated, my expectations for preview packages are that they are a toy mixed with a trailer for coming attractions. I'll use them to get a general idea of where the engine is headed, but I won't use them for any significant amount of time because things like constant API changes and the like mean that I'm constantly playing catch-up. It's not even worth using things that have come out of preview for at least six months sometimes because all the reference material (both from Unity and from third parties) is notoriously out of date.

Also, just as an aside: why on earth is there a button in the default installation of Unity that claims to gives me access to the sprite editor, but I have to install the 2d sprite package to actually use it? If there is an explicit link in the editor, I should not have to install a package. Either the link should be removed until I install the package, or the package should be installed by default.

 

Largely we stick to 2018.4. The specific minor release within this depends on how critically we might need a particular bug fix or update. We dare not update to 2019.4 yet for any in-progress projects.

Not in quite a long time. The last time that was the case, Unity had just begun to use the 2017.X notation and projects I'd created in Unity 4 could not be safely updated to 2017 but yet also could not be published any longer to the platforms they were created for from within Unity 4. That does predate the LTS concept, though.

It's less about the turnaround time for specific bugs, so much as it is what other people have mentioned in various posts in this topic. Rather than continue to build out newer and newer features that will end up with questionable quality and support, a commitment to prioritizing existing released features would be helpful. It's like AcidArrow says :

With elegance, it solves the problem that the old-fashioned "Export Unity Package" -> SomeFile.unitypackage process tried to solve, but never truly did. We can simply edit a manifest to reference shared code, shared prefabs, shared assets. It's a huge boon. It enables us to create advanced workflows that allows us to not only share our work with each other but share *relevant* work with each other. It allows us to keep concerns separate while also allowing us to blend them when necessary by declaring dependencies. The requirements to properly namespace and create assembly definitions enforce very disciplined coding patterns that are an overall boon to us.

Regarding Unity's packages, it allows us to more directly modify and extend the code that Unity ships. It allows us to more easily diagnose bugs in that code and offer bug fixes for them, whether or not those fixes end up integrated into the package when we file our reports.

Possibly a few different options:

• The version simply doesn't appear in the list of versions availble.
• The version appears in the list of versions available but is never selected by default.
• The version appears in the list of versions, and if it is selected a warning appears in the editor window.

On that last one, I would generally prefer that Unity still allows the package to be downloaded, in the event that we want to try to bring the package into shape on our own, but I would also be fine if the Install/Download button were simply disabled.

 

Hi @smcclelland. I would like to ask what's the ETA of shipping avoid reload whole domain feature? It means each time when I change one line of code, it will not domain reload all the dlls of the packages from Package Manager. That's the feature I really I hope it can ship at Unity 2020 release cycle. Currently with more features introduce as packages it continuously slow down Editor further and further. It really needs this kind of feature to really solve this problem. From what I know last year, the feature has been working on but this year I didn't hear any new update yet.

 

Somebody posted this in a chat group recently, and I think it kinda sums up why you're getting so much push back now:



In essence, you have a bunch of packages and new things that are "going to be great we promise", and a bunch of old stuff that's just... there, lingering.

Unity's actually pretty great now when you use 2018.4 LTS and don't include any major preview packages. It's the most stable it's been in a very long time. I expect 2019.4 will be decent once it's hardened, and I don't expect that to be when you ship it. At all.


I'm generally happy with the situation, but the only reason I think that I can be is that I'm regularly on the forums and am aware of all the stuff you do. Whenever I talk to my coworkers about the state of Unity, and everything it contains, their eyes blank over real quick, because there's so much stuff, and so much uncertainty.


The only real large problem you have, as far as I see it, is that your package developers keep chasing the bleeding edge. If almost all packages "has to target Unity 2020 due to engine changes", then you're not really making packages that are independent of the engine. You should probably try harder on this front - I'd be fine with the packages having smaller feature sets if they targeted hardened versions of the engine. That way we can actually use them for real things.

Ugh, all of your surveys are confusing and messy, but this is the worst one yet.

What is the total number of employees in your company at this mailing address?
That's strangely formulated! Drop "at this mailing address", it's not a disaster if the person answers for one of the companies they work for instead of the other.

If you have the ability to install features with packages in Unity, how would you feel? *
I do. I do have that ability. Why are you asking as if it's a hypotetical?

If you do not have the ability to install features with packages in Unity, how would you feel? *
That's the same question as the last one, with a not in front of it. Waht?

How important is it for you to install features with packages in Unity?
That's the same question again!

If you have the ability to install preview packages in Unity, how would you feel? *
I do, though! What's up? Did you make this questionnaire before Packman launched and forget to update it?

If you do not have the ability to install preview packages in Unity, how would you feel? *
That's the same question as the last one!

How important is it for you to install preview packages in Unity? *
You have asked me three questions. Why are you rephrasing questions?

I could keep going on. The absurdity of having to answer each question three times just makes me not answer the thing. I can't understand how you'd possibly get any value out of this mess.

 

First off, thank you for opening up this topic to discussion. It really shows promise.

I don't normally get involved in these discussions, because I'm a hardcore hobbyist riding the bleeding edge DOTS tech, but I do watch many of the other threads and I have a pretty good grasp of the root causes of frustration.

Before I get into that, one thing I will say is that packages, when done right, are a very good thing. The key is that the team behind a package needs to be active in the community for the Preview/Release/Verified workflow to make sense. Burst and QuickSearch are two excellent examples of packages done right. Preview is very much "Hey! We are developing this! Try it out and let us know if we are on the right track!" Release is what the team decides is a proper release. And Verified is when the Release was vetted against everything else. There are plenty of other benefits to packages. They just need to be handled well.

About 60% of the frustration I have seen with Unity's forward development stem from one of two issues.

Issue 1: SRP
Because packages are whitebox, marketing went ahead and advertised them as "Extendable". That was misleading. Sure, a team could go in and modify a package for their own needs, which will help medium to large studios out, but modifying packages is not an option for asset developers. I don't know why, but Unity has always written shaders in a spaghetti style. And so it becomes difficult for someone to go in and understand what is going on. In combination with that, ShaderGraph is completely closed off from extensions, so people cannot even use it with their own SRPs without forking it. And at the same time, marketing is advertising the exact opposite about the technology which is frustrating. Heck, even the Snaps HD team hasn't bothered to keep up!

Issue 2: LTS
As soon as 2019.4 rolls out, 2017.4 will stop being supported. Therefore, bug fixes that are being made to 2017.4 right now are kinda worthless because everyone is trying to get their projects up to 2018.4 which is less stable and more riddled with bugs because it hasn't been in LTS as long. I understand that Unity is in a state of transition and that it is difficult for them to stabilize things quickly. The problem is that people are having to ride these less-stable changes because the stable versions aren't going to be supported long enough.

There's a simple solution to the LTS issue that I'm surprised I haven't seen discussed more. Increase LTS to 4 years. That seems extreme and a lot of work, but add in this: LTS versions older than 2 years DO NOT receive bug fixes, only platform updates and security fixes. The platforms Unity supports update their toolchains too frequently for an unsupported Unity version to be useful. But after two years, any remaining bugs will be bugs the Unity community will learn workarounds for.

 

Personally i think HDRP looks amazing BUT these separate Render Pipelines have made all my purchased assets unusable unless i basically buy the entire asset again with "HDRP Support" I am not a rich man and am not a skilled software engineer capable to convert every asset I have bought to work. Unity is unusable now due to these iterations.

Why could we not have had 1 pipeline capable of doing it all like previously? Now i have to make a hard choice if i want to use one of 3 pipelines. 1 being the standard, which i assume you will soon no longer support and will be replaced by the Universal Render pipeline(Which i also have to rebuy all my assets) or the HDRP and rebuy all my assets.

Is there a solution to this problem? Id like to not have to convert 100 pages of code and not like have to rebuy everything.

 

Keep in mind surveys only give metrics about people willing to fill in the surveys.

There is a large group of unity users who simply don't know or don't care about surveys.

How do you keep track of those users in the metrics?

 

Go use the restroom, stretch a little, and get yourself a drink--and maybe an extra seat cushion--then settle in, because this is long!


My understanding of what TECH vs. LTS releases are supposed to be is very different from what they actually are in practice.

In theory, TECH is supposed to be stable but getting new features and occasionally making breaking changes (dropping deprecated features or making changes to APIs, etc) at each major release. LTS is supposed to be a feature frozen release with an emphasis on stability that will never break things by dropping features or making breaking API changes, but continues to have things updated to maintain platform support.

In reality, TECH releases are unstable betas, and LTS releases are semi-stable when they first launch and generally get more stable over time but also get forgotten or neglected by Unity who are busy working on the latest unstable beta (i.e. TECH) release while the known issues list for the LTS remains virtually unchanged (or growing) over many, many months.


To answer another question about alpha, beta, and final releases, I think of alpha as very raw, lots of instability, lots of potential changes expected in the future. Alpha is more of a proof of concept than a fully fleshed out and working system. I think of beta as feature complete, mostly stable, and mostly fleshed out but in need of finishing touches, bug fixes, and/or documentation. And final releases should have all that done and be very stable.

Personally I can't imagine making a final (non-beta) release that has any "known issues" in good conscience. And if/when I'm made aware of any issues, fixing those issues takes top priority before I continue development on further features.


In my opinion, Unity needs to ditch the TECH and LTS ideas as currently established and try again with something new. Here's how I'd like to see Unity approach releases:

Unity should have two public branches. We'll call them the Experimental and the Stable branches in this description. The names could be anything, but it's important that the name of each branch immediately makes it clear to newcomers that they should be using the Stable branch and should probably avoid the Experimental branch. This condition of clarity is not satisfied with the TECH/LTS nomenclature, IMO.

Any new and still-in-development features are introduced and further developed in the Experimental branch when they reach approximately the same level of development found in current beta TECH releases. This should be early enough to still be able to receive valuable feedback, but late enough for these features to be mostly stable and not break things in the editor.

Users should expect there to be bugs and problems in Experimental releases, but they should not be disastrous bugs most of the time. Upgrading an Experimental release to the next one could result in things breaking. Users should never be encouraged to use the Experimental release in marketing, blog posts, or Unity Hub. No blog posts should talk about cool new features in an Experimental release with the call to action to "try it out in your project today!" or similar. Instead, any blog posts highlighting new features in an Experimental release should be full of warnings and caveats about potential pitfalls and instability. The Experimental branch should be considered for advanced users only who need (or want) the bleeding edge.

If-and-only-if a feature is complete, fully documented, and has no known issues, it can be promoted to the next Stable release. I'll repeat for emphasis: If something isn't ready, it doesn't get promoted from the Experimental branch! There's no pre-determined release date for any specific feature. It's okay to have target release dates/versions. But if, for example, a feature is targeting the release of Unity 2020.2 (Stable branch) but the documentation isn't finished, or there's a "known issue" that was discovered at the last moment, then Unity 2020.2 comes and goes without the new feature. Yet again, for further emphasis: new features do not get merged into the stable branch until they are complete and stable!

IMO, 2019.3 could have been released on time and in a much less buggy state if some (or many) of the features which were holding it back were delayed until the 2020.1 release and 2019.3 could have been released without them.

Stable releases should be "rolling" with quarterly releases (at most) as features are promoted from Experimental to Stable. If there are no new features ready to be promoted from the Experimental branch, then there is no new major Stable release that quarter. Of course, "minor" releases with bug fixes, etc., can still happen as needed. In this way, each Stable release is a good mix of the current LTS and TECH releases, in that it should be generally very stable by the time it releases, and it won't get any breaking changes during its few months lifespan, ending support after the next major (quarterly) Stable version is released. This will allow for high stability in the Editor, but also allow projects to benefit from new features every few months as they have finished (FINISHED!!!) being developed.

All Stable releases should have a high priority on bug fixes! Bullet points on the Known Issues list should not languish for several months or years, or move from major version to the next major version!

Furthermore, once a year, a "snapshot" of the most recent Stable release will become an LTS version that acts more like current LTS versions. No new features. Only bug fixes, supported for 2 years to maintain platform compatibility, etc. The ultimate in stability and reliability.

In addition, any backward incompatible (i.e. breaking) changes should take place ONLY in the first Stable release AFTER the most recent LTS snapshot release. This means users can expect to safely upgrade from one Stable release to the next without their projects breaking, and can safely enjoy all new features and bug fixes introduced to Unity up until the time they ship their project without having to worry about feature deprecation or other upgrade woes.

To clarify what I mean by major and minor versions, I consider Unity products to be named as such: YEAR.Major.Minor.

I don't really care how the Experimental branch is versioned. I suppose if the Stable branch starts at something like YEAR.1.x then the Experimental branch could always be YEAR.0.x. As far as I'm concerned, each release of the Experimental branch could "obsolete" any previous release. It should be considered "bleeding edge" or "nightly" or whatever with practically no support for previous versions. People shouldn't be meant or encouraged to make actual projects in the Experimental branch. It should operate as a public beta for a relatively small niche of people who are of advanced/expert skill level with Unity.

But I suppose if you wanted more granularity to fit something more closely matching the current alpha/beta/TECH release you could use the word "Preview" which Unity seems to like so much, and have something like Experimental (alpha) and Preview (beta/TECH) branches. But again, the nomenclature ought to make it clear which one of them is relatively stable and feature complete (and could possibly get an early start on an actual project with) and which one is most likely riddled with bugs and not at all ready for actual work.

On the other hand, the Stable branch would ideally release sometime during Spring (April ±1 month) starting with a bumped YEAR number and resetting the Major and Minor numbers back to 1.0, much like current TECH releases. For example, using 2020 as the starting year, that first release sometime around Spring 2020 would be version 2020.1.0. Ideally we'd see one or two more major Stable releases in the form of 2020.2.0 and 2020.3.0 around Summer (July ±1 month) and Autumn (October ±1 month) respectively, but could possibly have only one more major Stable release (2020.2.0) through the rest of the year. And then at the end of the year (essentially starting Jan 1) the final Stable release (2020.3.x) for that year would receive an LTS "snapshot" and just be referred to publicly and in marketing as Unity 2020 LTS, but would retain the current LTS numbering (2020.4.x) to help with bug reporting, etc.

Then in the Spring of 2021 an update based off of the most recent 2020 LTS version would be released with any breaking changes due to deprecating old features or introducing new features, etc., it would be labeled 2021.1.0, and the cycle would repeat. Anybody who had shipped their game in 2020 and didn't want to or couldn't upgrade due to the breaking changes could stay with the 2020 LTS to have support and stability at that version/feature set for 2 more years. But most projects still in progress could safely upgrade to 2021.1 to enjoy the new features, just as they had upgraded from 2020.1 to 2020.2, etc., with the caveat that they would need/want to follow an upgrade guide (that is complete and finished by the time 2021.1 launches instead of being MIA like the upgrade guides for the past year still are (see upgrade guides for 2019.3, 2019.2, 2019.1, and 2018.4 for reference)) to work around any potential issues they would encounter due to the breaking changes.

Due to there being NO breaking changes between any other versions, there would be a single upgrade guide per Unity YEAR version ("Upgrading to Unity 2020" or "Upgrading to Unity 2021") instead of one per major version released.

In all of this, development priority should be given to fixing bugs in the LTS, then the Stable releases, and lastly the Experimental releases. No known issue should exist for more than a couple of months if it can be helped. Any known issue that exists longer than that should figuratively sound a klaxon at Unity Tech to "stop the production line" and resources should be taken off development of new features and Experimental releases and reallocated in an "all hands on deck" manner toward fixing the bugs.

Obviously this last bit is a bit oversimplified due to the fact that, for example, it doesn't help to stop a graphics expert from working on the latest SRP features to solve a bug related to networking. And it also can hurt to have too many cooks in the kitchen, so to speak. But the point remains: Stability and bug fixes should have priority over new features, because new features == new bugs.

 

Echoing the others here, thanks for reaching out to us on this. It means a lot

RELEASES

• What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?

It's convoluted. Don't reinvent the wheel here.
- 2020 Alpha... use at your own peril, we're adding stuff to this all the time and also fixing bugs.
- 2020 Beta... Start playing around with the alpha features as we stabilise and document them
- 2020 (LTS)... Trust that this is stable and fully documented and that we won't add any core non-Package features.

• When you see a new Unity release, what is your expectation of quality?

Oh so low usually. With a complete disregard for all the feedback received we've been providing. Having said that, I'm on 2020.0.1a25 and it has been the most stable version of Unity yet for me. Not sure if that stability has worked its way to 2019.3 but it's promising.

• Do you expect different levels of quality or completeness based on the release distinction?

As above, and as per tradition.

Alpha = not feature complete or documented.
Beta = feature complete, documentation and bug fixes in the works.
LTS = fully feature complete and documented.

But each version should go through a DEV->UAT->PROD process internal to UT before being made a release.

• What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?

For me it's the opposite. As a serious hobbyist, when I hear you're deprecating the standard pipeline - as well as a bunch of other things - I have the option of:
- learning and using features that will be outdated
- using the new "production ready" features and SRPs.
The choice seemed simple to me. But opting for the more cutting-edge releases has been a huge mistake and I've wasted a year of production, without picking up any new skills. My time has been spent trying to figure out if stuff is broken at your end or at mine.

PACKAGES

• When we say something is in Preview, what does that mean to you? Why do you feel that way?

Preview means: it's ready to be used but usage in production is highly risky and discouraged (you're on your own). It also means that the API may change.

• Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?

I'm driven to use something in Preview to see if it miraculously fixes all the issues I've been having... eg. Will the Terrain Tools make working with Unity terrains more useable? Will DOTS Hybrid work with URP? etc. It's also an opportunity for me to give feedback that will be ignored (like... how ridiculous it is from a UX standpoint that I need to click on the "Add" button in the Hub to check if I'm on the latest version.)

MY ASSETS

It used to be that checking and updating 'My Assets' would take me 1-2 hours in 2019 via the old in-editor store. I would sometimes have to wait 3-10 minutes after each click (or even scrolling). I saw the Package Manager as a way to get around that hell. And so this was a major motivation for trying out 2020 as I was told that the in-editor asset store was being phased out and that the PM would solve all my issues and include dependency tracking, etc. I hadn't realised that updating would mean i would miss out on: accurate version numbers, accurate release dates, having the possibility for updates to actually just show up in the Package Manager (for several releases, 'My Assets' in the PM did not show any updates), etc. I hadn't realise this because the Package Manager is not in 'preview' and so meant to have been properly tested (see above).

THE IDEAL

- Move the Package Manager (inc. a version of My Assets that also includes screenshots, videos, etc.) to the Hub.
- Embed Unity Connect / some Discord-like (or Discourse-like) forum functionality in the Hub and encourage asset developers to use that so that I don't need to check their website, their Discord and their unsearchable Unity.com forum page for updates.
- Make it so that I can't install that new Properties or Serialization package if it's know to be incompatible with the DOTS packages I already have in my project. Or at least warn me.
- Don't just tell me an asset store package wants to update my PM packages... Tell me which ones so that I don't end up installing Ads and other crap I actually really didn't need for the package to work.
- Reintroduce surface shaders so that asset developers don't have to maintain 12 different code bases.
- Allow us to more easily submit improvements to the docs as OpenFrameworks does. Also, allow how-tos to include user contributions (vetted by UT via Github) as does OpenFrameworks.
- Ditch this unsearchable forum and use Discourse instead. Try searching within long threads on this forum. Also try searching for a 3 letter word (such as URP). And then try searching for something on a long thread from the OpenFrameworks forum. Better access to information = less likelihood you'll see us complaining about the one thing on a bunch of different threads because we're not sure which team owns the error we're experiencing.

 

PS - the survey is terrible. At least include a text input box for each question.

eg. I would feel perfectly fine not having "the ability to install features with packages in Unity" if by that you mean that I can install those features through the Hub instead. Otherwise I would feel that is a completely naff rhetorical question if actually meant literally.

PS - If I'm installing URP 8.0.1, don't I need the Core SRP 8.0.1 package for it to work? Then why not ask me if I want to automatically install all of the required and known dependencies. Seems like something super obvious from a UX standpoint.

hot tips:
- set up a UX team. (Or hire qualified UX specialists like @Lars-Steenhoff or myself)
- do UAT with real users (us)

 

Spoiler: Opportunity taken to drop some id software wisdom

It's taken from The Early Days of id Software, great talk imo!

I imagine, for Unity Technologies, fixing bugs might cause to break and introduce instability in user projects, so it's probably a thin line to decide what things to fix where.

 

Tech releases should be for that. Break down the engine for the time being to ensure stable and robust LTS later.

 

I don't have time to read through every post in this entire thread this morning, but as several people have already pointed out the LTS versions are meaningless as stable versions when you have a whole bunch of packages in them. This is because fixes to packages require you to upgrade your Unity version, so you loose the stability. As we create a continuous product and not one off projects we want to be on the LTS versions each year and not have to risk upgrading half way through the year to fix packages.

Please figure out a way to include packages in the LTS cycles!

 

There is no point in changing the naming scheme at this point in time, because it will only add to the confusion.

There is a point in detaching packages from unity versions.

Each recent package should work on the latest LTS version and not require a newer unity version.

This way we can have a stable core and still use the latest packages at our own risk. There should also be a tag LTS certified in a stable package version.

This way you know its been tested with the LTS version.