Supporting Unity 4 and Unity 5... Best Practices?

** Repost - Getting lost Assets and Asset Store forum **

I have several assets on the Asset Store that do pretty well. So, I'm trying to figure out the best approach to support both U4 and U5 users.

What's the best way to manage the code-base since there are some API differences?

1. Use compiler directives in scripts as needed. This way the *.cs files are exactly the same between the U4 and U5 projects.

2. Totally split the projects and update the code separately. This keeps the code a bit cleaner for each project, but could be a nightmare for me.

3. Something else?

What works for you?

Thanks

 

Forgive me for this tangential question, but what specific API differences are you worried about?

I know that Unity 5 is requiring scripts to switch to GetComponent<> for a lot of stuff, but GetComponent<> works fine in pre-5, too, so I assume you must have something else in mind.

 

Hey Antistone,

When I load up one of my U4 projects in U5, I get about 50 extra warning messages. For example:

`UnityEngine.AnimatorStateInfo.nameHash' is obsolete: `Use AnimatorStateInfo.fullPathHash instead.'
`UnityEditor.Undo.RegisterUndo(UnityEngine.Object[], string)' is obsolete: `Use Undo.RecordObjects instead'

I know the warnings aren't critical, but I like to deliver clean code.

There's also some new features I read about in U5 that I'd like to use.

Even without these, the entire project is different for U4 vs. U5. So that means we have the same files in separate places. So, I think the "best practices" question of how to maintain the same project across separate versions of Unity is still valid.

Hope that helps.

 

Seeing as official release of it was just today... the amount of people who have fully combed through it and designated a "best practices" are going to be few and far between.

 

Thought, asset store publishers had access to unity 5 beta pro for quiet some time already.
I personally tend to use preprocessor directives since they deliver the best split. However, alot of stuff can already be solved by writing code which works for both, U4 and U5. ( Take the GetComponent<> method as example )

 

This is literally precisely the sort of situation for which compiler directives were invented, so you're unlikely to find a better solution. Splitting into two projects would make it more difficult to deliver fixes in shared code for very little benefit.

You should also keep in mind that with clever placement of compiler directives, you can cut the copy/paste down to virtually nothing. For example:

Code (csharp):

1.  
2.         myThing.AnimatorStateInfo.
3. #if UNITY_5
4.             fullPathHash
5. #else
6.             nameHash
7. #endif
8.             = myHashValue;
9.  

And of course, always keep in mind places (like the GetComponent changes) where you can write one line of code that works for both versions.

 

So, this is good. I was thinking I'd go down the compiler directive approach as well... at least as a start. Although I didn't think about the extreme @GrandOpener shows...interesting.

This leaves us with the situation where the same file is used in different projects and now different project versions. Of course that's if we want to submit packages with U5 specific features while still supporting U4 users.

I was playing with GitHub last night, but you can't Fork to yourself. WinMerge is working, but there's no version control or automatic syncing. Any thoughts?

I dug through Google last night and there's some SVN command line solutions, but everything feels like a hack... (plus after 20 years of coding...I hate command line solutions ). Anything working well for you?

 

You can still use the same codebase; the compiler directives control this. And if each source file has the same .meta file, you won't get duplicates across packages.

A tip from painful experience: Don't submit precompiled DLLs; submit source. If you precompile a DLL, the compiler directives are set in stone. You'll end up having to provide separate DLLs for each Unity version and/or platform.

 

Thanks @TonyLi

I thought I had to submit U5 packages using U5. What I'm finding is that if I test my current U4 projects in U5, find the needed changes, do the directives in U4, and then submit using U4... it's all working.

It still feels a little weird.

For example, U4 wants "AnimatorStateInfo.nameHash" and U5 wants "AnimatorStateInfo.fullPathHash". So...

1. I make the directive change in U4
2. I copy the whole project to a different directory
3. I load the copy into U5 (which upgrades the project) and test.
4. I go back to U4 to modify or fix.
<repeat 3 + 4>
5. I go back to U4 and submit so the Asset Store says "Requires Unity 4.6.1 or higher".

Now, someone with 4.6.1 or 5.0 can download the package.

It's working, but feels like an odd juggle. No complaints...just making sure I'm doing things as efficiently as possible.

 

Hi @Tryz - I use uTomate to automate actions. One of my uTomate action plans tests compilation. I develop everything in a Unity 4.3.4 project. When I hit the uTomate button, it runs the code through the compilers for Unity 4.3.4, 4.5.5, 4.6, and 5.0, no juggling required.

 

Interesting. I'll check it out. Thanks!