I’m currently working on ScoreFlash and as I decided to publish this with Unity 3.4.2, each time I make any change in the project (which is pretty much all the time), Visual Studio goes through the “upgrade project” wizard - sometimes multiple times in row.
I even considered installing 3.3 for the purpose of building my asset store packages - but then it turned out that 3.3 wouldn’t even install on my machine.
So, I was wondering: Is it worth it? How many of you are actually still using Unity 3.4.2? Is anyone really still using 3.3 (except people publishing to the Asset Store using that version to make sure everyone can use their assets)?
Please only check the version you primarily work with.
There is plenty of reason. Most serious dev houses will refuse to update their engines until the project ships. If they bump into an issue, they do a work-around, but they dont update.
Any update can potentially introduce new bugs that force a reset on the entire Q&A process, something that can be expensive for larger titles. When I am deep enough on a project I tend to do the same, only updating near the end once I feel I must do another full Q&A pass anyways.
I lost about two months of work when Unity 3.0 shipped. I didn’t back up my project files, and man, it smashed the crap out of them. So I’m holding off on U4 until I get some free time to play with it. 3.5.6 on the other hand is rock solid and fixed a few bugs that were holding me up.
Yea, got to say for the most part, 3.5.6 is essential for iOS developers. Not everyone using Unity is doing iOS, though. And even then, if you doing a portrait only app for the iPhone (ignoring iPad) you may be able to get away ignoring some of the issues and hacking the solutions in XCode.
Why wouldn’t 3.3 install on your machine? That’s very odd indeed, unless between 3.3 and 3.4 Unity started supporting a new OS version?
Anyway for asset store packages I believe you should support the oldest Unity version you can, since as has been pointed out developers have many reasons for not updating to the latest versions. I myself have 3.3 and 3.5.2 (and even 2.6) installed as I have client projects that are based on those versions.
If your asset store package requires anything above those versions then it just becomes more hassle to use. For example if it uses 3.5.6 I can’t even download it, unless I install that version of Unity. This obviously means you can be limiting your market before potential customers even consider purchasing your asset, which is obviously not good business.
Yeah, aside from bug fix releases I wouldn’t bother doing updates during projects. You should be working and planning based on what’s available, not what might be in a future update, so there should be no need, and there’s no reason to risk the update breaking things. If you do update, it should be a planned thing.
That’s probably the case. I remember that it installed fine on Snow Leopard. However, now I have Lion - and when I try to open the package, I get an error message.
Wish that were true, but unfortunately 3.5.x breaks the Community Ocean Shader so for those projects I’m working on that use it I’m stuck on 3.4.2 for now. Some day I’ll either fix the shader for 3.5.x+ or buy the new Triton shader. Otherwise, I would agree that any new project that I might start I would very likely use the latest version of Unity (unless some asset I needed wasn’t supported).
To basically echo what a few other people said, I disagree. Sometimes there are compatibility issues when upgrading to the next latest and greatest of anything. If there ever was a compatibility issue when you upgraded, you just lost that much time that could be spent developing with the engine version you started with.
Yup, especially with going from 3.4.2 to 3.5 there were some changes, that severely wrecked one of my own projects. Eventually, I’ll have to fix it because I do need 3.5 “stuff” in that project - but I believe there’s very valid reasons to keep 3.4.2 going for a little while (even if that does mean quite a bit of inconvenience and extra time investments in package development).
This is exactly why we chose not to update to 3.5 with my title. The Product Managers and QA team would have been less than impressed as it would have forced a reboot on the entire QA process. With publishing deadlines and release dates given to distributors etc that would not have been on my list of good ideas.
So, I am only seeing 3.5 for the first time now as I start my next project, albeit keeping 3.4 on a second machine, for any patches that may be required to the shipped title.
Just curious: Why on a second machine? Generally, different Unity versions do work quite well when installed side by side (a little caution never hurts, though ). I have a few Unity icons in my dock, one saying Unity3.4.2, another one Unity3.5.6 … and Unity4beta. The only inconvenience is that I have to carefully rename folders before updating any version so that I don’t trash an existing install. Also, it’s good to have “Show project wizard at startup” active and be careful which project you open with which version of Unity.
Now that 4.0 has been out for a little while I was wondering if people have changed their minds. Is 3.4.2 support still necessary? It becomes increasingly difficult to maintain the old version so I’m considering dropping 3.4.2 for ScoreFlash - unless some customers say they need it (but this poll is general; I’ll be linking to it from the official ScoreFlash thread: Score Flash: Easy to use GUI for Scores, PowerUps, Achievements, Tutorials (Scrolling Combat Text on Steroids ))
Well i’ve changed my installed versions slightly. I now have 2.6, 3.5.2, 3.5.7 and 4.0 installed ( Windows ). Though off-hand I can’t think of a good reason why i have 3.5.2 vs 3.5.7. Might be I was just in the process of testing if there were any changes issues between them for recent client projects and never got round to retiring 3.5.2.
Actually thinking about it, I believe I installed 3.5.7 due to a massive memory issue (possibly a leak) when having tens of thousands of gameobjects/materials loaded. There is definitely a problem as the test project constantly saves 264mb at runtime between 3.5.x and 4.0, though i’m not yet convinced that even in 4.0 that all memory usage I’m seeing is needed. So unless I find some reason not to, I’ll probably retire 3.5.2 in the next few weeks.
However that’s not to say that I wont end up re-installing an old version for older projects should I need to. So i’m still of the opinion that you should support the oldest version possible. The only reason to change is if the asset requires features in a specific version of Unity in which case that should become the min spec version.
Out of interest what is it specifically that makes it difficult to support 3.4.2 for ScoreFlash? Alternatively what is it about more recent versions that make ScoreFlash better or easier to develop?
I primarily use 3.5, as I haven’t found much of a reason to upgrade yet to 4. As imaginaryhuman said, it’s a good baseline. Most people here are using at least 3.5.
The thing that’s most annoying is that 3.4.2 still uses the old Visual Studio 2008 format for solutions. So each time I make a change in my Unity project that results in re-creating the solution (which is quite frequently), Visual Studio complains and needs to upgrade the solution files. This is not a big deal - but after a while it becomes very annoying. Using Unity 3.5, I can use both Visual Studio 2010 and Visual Studio 2012 without any hassles.
One 3.5 feature that I’m using that isn’t available in 3.4.2 is Screen.dpi. This is useful to figure out whether ScoreFlash is running on a high density display (e.g. Retina on iOS). For 3.4.2, I have some heuristics which should work in most cases - but being able to check Screen.dpi is a much cleaner (and more reliable) approach. At least on mobile (Screen.dpi doesn’t give useful results on desktop … yet ).
Another thing that has changed between 3.4 and 3.5 is the way I save changes made while playing. One approach only works in 3.4, another only in 3.5; so I need to maintain both as long as I support 3.4. Also, 3.4 doesn’t have serializedObject available in Editor (that’s not a big deal, though - but still it adds stuff that makes the code more ugly). 3.5 has PrefabUtility.DisconnectPrefabInstance() - 3.4 does not (it doesn’t even have PrefabUtility - instead you need to use EditorUtility).
Then there’s stuff like having to get everything from 3.4 to 3.5 just to test the NGUI integration (NGUI requires 3.5, so I can’t do that in 3.4). When something’s wrong there, I need to fix it in my 3.4.2 project, port those changes to 3.5 again, test again etc.
All these things are mostly just inconvenient. However, the thing that really concerns me at the moment is that in 3.4.2, every once in a while Unity loses some references when I re-open the project after working on it. It then cleans them up and that basically trashes the project (e.g. prefabs are gone which results in most of the examples breaking). I can fix that relatively easily by simply undoing the changes that Unity applied using Asset Server - but if that ever happens to one of my customers, that would suck big time. They could probably re-import the package but that’s simply not the kind of experience I want someone to have with my package. Something like that never happened for me in 3.5.x.