Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Publishing an asset for multiple Unity versions

Discussion in 'Assets and Asset Store' started by syscrusher, Nov 18, 2017.

  1. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    I note from the Asset Store Submission Guidelines that Unity recommends uploading with the oldest Unity version that my asset can support (in my case, 5.4). I've tested, and the asset I plan to publish works correctly with all versions through 2017.2 with no code changes. When I install into those later versions, though, there are a couple of APIs that Unity automatically upgrades.

    Is there a way that I can upload version-optimized packages for my asset, by using different Unity versions at my end for the uploads, so the Asset Store can offer my customers a pre-updated version and save them some import time?
     
  2. Mauri

    Mauri

    Joined:
    Dec 9, 2010
    Posts:
    2,663
    1. Create a new draft of your Asset in your publisher area by clicking on your desired Package and press the "Create New Draft" button.
    2. Upload your Asset with the Unity versions you want to support via the Asset Store Tools.
    3. If you now open your publisher backend and click on your Package again after uploading, you'll see a row called "Unity Package" on the right hand side. Verify that the desired Unity versions are listed there and submit your Package to the Asset Store Team by clicking the "Go To Draft" button and then "Submit package for approval".
     
    Last edited: Nov 18, 2017
    syscrusher likes this.
  3. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    Thanks! it's good to know that's possible. I was confused by the suggestion in the docs about uploading the oldest version, and no mention of multiples. I haven't created a merchant profile yet because I'm still a couple of days from being ready to submit the asset. (The code and docs are done, but I'm working on video tutorials and waiting for an artist to finish some marketing graphics for me.)

    I appreciate the detailed response!
     
  4. Mauri

    Mauri

    Joined:
    Dec 9, 2010
    Posts:
    2,663
    I do should have explained Step 2 better, now that I see it :oops:

    Basically, you have - for example - three different Unity versions. For each version, you create a new Project that contains your Asset that's adapted to the specific version. To upload your Asset, you'll need to open each Unity Editor one by one and upload its contents via the Asset Store Tools.

    Open Unity 5.3.4 > upload your Asset > finished uploading & everything ok? Close the Editor! --- Open Unity 2017.1 > upload your Asset > finished uploading & everything ok? Close the Editor! > etc...
     
    syscrusher likes this.
  5. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    Great! That's almost exactly the workflow I'm already using for my own testing, except that instead of "upload to the asset store" from each version, it's "save to a *.unitypackage file on my local drive". Thanks for the additional info.
     
  6. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    Is there no easier way? D:

    What if your asset works for really-really old versions?
     
  7. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    Then download the oldest version and submit from that. But make sure it still works well with the latest versions, too.
     
  8. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    @TonyLi
    So you're saying that as long as I submit from the oldest version, my asset should show for every new version too? -- If so, that's good to know. The asset store seems like a jungle sometimes with all the hoops you have to jump through to take advantage of it completely.

    Sadly, hard-disk space is sort of at a minimum for me -- all to change a version number. :/
     
  9. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    Part of this depends on whether importing your asset into newer Unity versions causes Unity to do any automatic API updates on scripts, and if so, do those "Just Work" for the user or are there things they need to tweak?

    I've seen reviews where assets were dinged (usually gently) for API updates during import. What you might want to do is test your asset with an exported package from the oldest Unity version you choose to support, import it into Unity 2017.3, and if you get no automated API updates, you could just post versions for the older Unity version on the store. If there are API updates, figure out which specific Unity versions introduced the new APIs and release your asset (additionally) for the versions where the API changed. You may find, for example, that the Unity 5.4 version of your asset works without changes on Unity 5.4, 5.5, and 5.6, has an automated API upgrade when importing to 2017.1, then that updated version works fine on 2017.1, 2017.2, and 2017.3. In that case, you could release for Unity 5.4 and Unity 2017.1, and there would be coverage for a wide range of versions with only two uploads by you.
     
    awesomedata and TonyLi like this.
  10. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    Thanks a lot @syscrusher -- that helps clarify things a lot!

    I had been under the impression that it was necessary to upload a version for /all/ versions of Unity I wanted to support in order for it to appear to all possible users in the Asset Store.

    I'm really glad to know that's not the case -- My asset shouldn't require any weird API changes -- it's pretty straightforward and would probably work pre-5.0 easily.
     
  11. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    I totally understand. I have over a dozen versions installed. Since your asset is an editor extension, you can save space by excluding build targets, Standard Assets, example projects, etc. In an ideal world, you'd have the versions with major API changes installed -- 4.x, 5.0, 5.1, 5.3, 2017.1, and 2017.3 -- so you could let the auto-updater update your code and get rid of any warnings, and so you could identify any API deprecations. For example, in 2017.3 you can no longer use EditorApplication.playmodeStateChanged. You have to use EditorApplication.playModeStateChanged.

    Or you could just submit in the earliest version and rely on customers to let you know if your asset throws errors or warnings in other versions. But that's taking a gamble on an upset customer and a bad review.

    One mitigating factor is that almost no one uses 4.x, and a tiny fraction use anything earlier than 5.5. Frankly, with a new asset I wouldn't bother supporting anything earlier than 5.6 unless there's actual customer demand for it.
     
    syscrusher likes this.
  12. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    You're welcome. I'm fairly new at this, too. :)

    Did you mean pre- or post-5.0? Remember, as @TonyLi has said, you upload for the oldest version you plan to support. The Asset Store download won't let Unity download an asset from a later version than itself. If you upload for Unity 5.6 and I have Unity 5.5, the store page won't let me download.

    Be cautious if you really mean pre-5.0, because people may shy away from an asset that's tagged as being too old, even though the asset works fine with 5.x, because they may incorrectly assume it "hasn't been updated in years". I'd do at least a 5.0 upload even if you also do a 4.x upload, just to give buyers that extra bit of reassurance.

    Of course, some of this depends on whether your asset is art or scripts or sounds...etc. If the asset is all sound files, Unity versions aren't all that important.
     
  13. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    That's a good point. I myself used 5.4 for a good while (only recently upgraded to 2017.1 myself), but that was due to developing an asset for it and wanting to stay on the oldest version as much as possible due to the issue of hard disk space. Unity just moved faster than I anticipated with subsequent versions, so I was forced to update lol.


    Sadly I did mean /pre/ and yet, now that you mention it, I can see how you're absolutely right that this might be a bad idea.

    This issue is something I had considered early-on, but I hadn't really thought much into since because I didn't know the specifics of how Unity actually handled the versioning system, so thank you for pointing that out to me. I am about to release Snapcam 2.0 in the next few days and really wanted to be sure I reached as many people as possible with it. However, I probably could have bombed it with them thinking it's "out of date" automatically, despite its "newness" on the market. That said, I wouldn't mind having that "new" tag on it for a little bit longer since Snapcam is still a very young asset that already packs a lot of punch with its new navigation system. I'm currently working on a better video for showcasing it (but my video editing skills are subpar and in their infancy), so that's been holding me back for some time. I think I'm finally at the point where I'm able to do the basics though! -- That said, I plan to release Snapcam within a day or two, so I just wanted you guys to know your advice here is very timely! :)

    Thanks again for your help guys! -- Maybe things will go better this time if I release for a later version than 5.4.1f ... xP
     
  14. huwb

    huwb

    Joined:
    Oct 19, 2013
    Posts:
    24
    (Apologies for reviving a bit of an ancient thread here but it was the first result when i googled).

    I have different editor version packages of my asset due to the rename from LWRP to URP. I frequently hear reports that people find themselves with the wrong variant (i.e. they're using URP and they have the LWRP asset package installed).

    The typical way this happens is someone installs the asset on 2019.2 and then upgrades to 2019.3, but are not then served the correct variant, i.e. they are left with the 2019.2 version of my package. Is this expected to work?

    Unfortunately for at least a few of my users, uninstalling and reinstalling from the store does not fix the issue. One reported that they had to navigate to the editor app data and remove the cached unitypackage, in a path like C:\Users<your_username>\AppData\Roaming\Unity\Asset Store-5.x\Unity Technologies . Has anyone else run into this?

    Thanks
     
    syscrusher likes this.
  15. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    The SRP version of my asset is still under development (because I'm adding a lot of other new features besides that, and my customers have said they're not in a hurry for SRP as such), so I haven't encountered this issue, but I appreciate the heads-up and will be sure to test in that scenario. Thanks for posting.