How far back should Assets support?

Hi all, I've currently got my Asset on the store, but atm you need a pretty recent version of Unity for it
So the question is, how far back should I or people in general try to support? It would mean downloading and older version of unity, and using some platform dependant compilation to strip out functionality that needs the newer versions, but is it worth it?

Can you have two assets on the store for different unity versions?

And is there a way to see if it is older than version X.Y.Z when using preprocessors?

Thanks

 

You should always try to maximize sales when it makes sense. Usually pay attention to the statistics provided by Unity.

http://forum.unity3d.com/threads/unity-version-usage-might-be-useful-for-package-devs.250891/

In general, Unity 4.6 seems to be the natural place to go back for currently on that graph (if it doesn't only work in newer versions). You can certainly upload as many versions as you want to the asset store (I have one currently that has a 4.3, 4.6, and 5.0 version) the user will get the highest available version that is lower than the version of Unity they are currently running. You simply upload more than one to the asset store.

There are many preprocessors for Unity versions, if you want different code for different versions, simply use them just like you would on different platforms. The one thing to keep in mind though especially if you have a lot of example scenes is you should make this decision up front and make the examples on the lowest version you support. It's always possible to import into newer versions of unity but not the other way around. A scene made in 4.6 will import (and sometimes convert) into Unity 5.0. However if you try and import a 5.0 scene in 4.6 it will not work (obviously) so you would have to recreate all of those examples if you decided to support lower after the fact.

 

Ah right, thank you for that Much appreciated
Few questions, if you uploaded multiple assets via the same name, but with different unity versions, would it be automatically handled for you?
If you use preprocessors, is there any way to do inequalities? As i feel its gonna be really tedious to check every single version, instead of say, eariler than 5.2.1

 

When in draft for any version simply upload the package like normal from all the versions you are going to upload to the store. For example, lets say you have a 4.6 and 5.0 version upload the package from Unity 4.6, and then upload the package again from 5.0 via the asset store tools. When you look at your draft version online you will notice that both versions are there and you can then submit for review. The asset store automatically has the user download the right version.

Historically there haven't been defines that are written like (less than unity 5) or (greater than unity 4.6). There are the all encompassing major version ones like UNITY_4 or the minor ones like UNITY_5_1. So if you are in between you generally do want to or all the minor versions in a statement (it's a little annoying but only really takes a bit) just be careful to put all the future versions that aren't out yet you don't want it to break when that version comes out. I believe in one of the other threads Unity might add a greater than define for an upcoming version but not sure which one and if its a one time thing or not.

 

For the most part only really big businesses would want you to keep older versions if they use your assets but they are so big they likely have the manpower in house to handle your drop of support.

I think 5.x is enough but you might want to ask Unity the distribution of -4.5x vs 4.5x vs 5.x and make your decision based on that but given the trend of Unity and others dropping support for iOS 6, Windows XP, and so on you have to consider making a more useful product vs making a product that's marginally more used.

 

5.3.4


4.6 is console mostly, or people finishing up. For 5.x series, there's no benefit to being less than 5.3.4 as previous to this is too buggy IMHO.

 

When creating an asset, you can upload multiple packages from various versions of Unity. This way you can have versions that are compatible with 4.x, but also have a version optimized for 5.x with updated script APIs and PBR materials, for example.

Not sure I'm understanding the question properly or not, but the version you use to upload will be the minimum required version the package supports. So if you want to support all of 5.x, you should upload using the earliest version of 5.x that contains the features you're using.

 

Thanks for all the input
Out of interest, what version are all of you on right now?

 

So you feel that other than people making console games (the big dogs really, out of my target audience tbh), are gonna be up to date with latest unity 5 releases?

 

I needed some platform dependant code if i want to support pre Unity 5, but I wanted to know if there was a way to check if it was older than a unity version, instead of if it was that unity version

 

This is not correct. Definitely go by the statistics Unity publishes. 10% of people still on Unity 4 is nothing to scoff at. I do get periodic support request occasionally for it still and not just from studios (or prospective buyers wanting to make sure there is support before they buy). On the Unity 5 side of things definitely plenty still using prior to 5.3.

 

Those 10% people using Unity 4.x likely aren't going to buy your product in sufficient quantities to justify the hours you'll spend adding all those messy conditionals to your code. It's a huge factor in your decision that none of those 10% of Unity 4.x people have or can buy your product already.

I use 5.4.0 Beta 10 and have reported 3 bugs in 2 days.

I had to search what product you have...I'd don't have it but will buy it sometime soon and combine with Unity's automated test tools. I have lots of assets, bought & otherwise, and plenty of those have been deprecated.

I really just goof around with Unity from time to time. Since they made the betas available from now on I will be using the latest beta as there are too many improvements offered to stick with older versions of Unity even if I do wind up reporting more bugs. I don't worry about having the latest released stable version for my product release or product support when I mess with Unity but rather what Unity's offering that I can use to make my product better or easier to make.

 

This is a decision each asset author will have to decide for themselves. I didn't want to have to deal with support requests for older versions of Unity, so when I published my asset for Unity 5, I actually removed the 4.6 version. I just didn't want to have to dedicate the time potentially responding to support requests for old versions, so I figured I'd go for the largest demographic and lose whatever potential sales I'd get with the smaller groups that haven't upgraded yet.

 

I'd agree if you have to do that, most of the time you don't especially if you are using areas of the API that haven't changed in awhile. Most products its pretty clear where to start support (ie. PBR starts with Unity 5, UNET starts with 5.1, Apple TV started with 5.3.1) but anything else if it doesn't add any time why not support it? It certainly does add more sales and a larger pool for those to buy your product.

Totally agree if there is a lot of extra effort in supporting Unity 4 still (I presume the product deals with something that changed). This is not the case for all assets. You should always weight the amount of extra time you would have to spend vs. the potential increase in sales. If its not worth it then you definitely should drop support. If it doesn't cost you any extra time you definitely should still support it.

 

You can always use an else as a catch all. So check if 4.6, then if 5.0, 5.1, 5.3, then else. The else will catch 5.3 and any more recent versions.

 

Oh, thank you! Didn't expect to be making any potential sales, rather just getting advice
Yeah what you're saying is a very valid point, I might add support for older versions of Unity on a request basis
Are the betas available to everyone now or pro only?

 

In my case I would have to change the API in a few areas, and disable all the build platforms for versions they havn't been added in yet (eg. WebGL, tvOS)