Completely agree that Adobe should consider including a Migration Assistant/Wizard into the Flash Builder 4 application.
Howevver, as an Action Script 3 apprentice guru, I am very disappointed with FlashBuilder 4.
Based on my past observation, I rather consider it simply a RAID Action Script 3 development environment.
Full scripting maturity and flexibility can only be accomplished through 100% Action Script scripting as every mature guru programmer fully knows.
Sorry guys, stop showing your belly and start rolling up your sleeves and come back to basic programming concepts if you want to surpass Silverlight coders.
For me, Flex Builder has been an exceptional tool for development.
Through its AS3 and MXML formats, in addition to its rich component
set, I've been able to realize extremely complex ideas in a very short
time. So, in regards to Flex, I'm very happy.
Now, what I don't understand is why the migration of a modern Flex 3
project would need to go through so much pain to look and work the
same. I would think that, despite the new features provided in Flash
Builder 4, that a Flex 3 project would (should) open and operate
EXACTLY the same. Alas no.
I have, however, seen these differences outside of Flash Builder 4.
I'm experiencing aesthetic and functionality breaks in my application
nearly every time I update the Flex 4 SDK in Flex Builder 3. First,
when migrating from the 220.127.116.1100 SDK to version 18.104.22.16810 I had to
change the namespaces to get my .css style to look the same. (still
doesn't quite look perfect). Now, after fixing all that I updated
from version 22.214.171.12410 to 126.96.36.19944 and everything broke again. Man.
Very frustrating to say the least.
Regardless, I consider Flex 3 to be a powerful, flexible
and overall astounding application for realizing ideas. I was so very,
very excited prior to Flash Builder 4. I couldn't wait to get my
project in there and take advantage of the new things the Flex (Flash
Builder) team had thought of. Alas, however, it has been quite painful
and disappointing from the start.
Again, for all those Flex 3 developers who aren't fully fluent in the
myriad of elements involved with Flash Builder 4 (such as namespaces and
so forth) a simple migration assistant would be a great thing indeed. Just a few
clicks of a button and all would be changed, updated, altered and fixed to ensure
those loyal Flex 3 developers will have nothing to worry about. This would
probably be the BIGGEST thing Flash Builder 4 could offer - seamless migration!
I see a few issues with migration wizards, but the biggest concern is they introduce laziness(lack of due care by the developer once a conversion has taken place). The true coder's IDE is still fairly new to Adobe so we should expect the unexpected.
Borland/Codegear and Microsoft have been developing IDE's for the better part of 2 decades, both have had conversion wizards thru the years and these wizards tended to cuase more issues than they were worth especially when there was a major version change and lets face it this is the scenario where someone would more likely want a wizard.
Flex 4 sdk is a major shift from Flex 3, Where as 2-3 was an upgrade I don't see the same for 3-4, As soon as I started using the Flex 4 sdk my first thought was to start labeling FB3 code as legacy.
The experience gained moving legacy code into a current/evolving environment is something you can't buy.
Adobe does have reference material documenting FB3 to FB4 changes but it needs to be more concise, updated more frequently (in-line with 'stable' sdk builds).
A well documented migration giudeline with examples would be invaluable and far more effective than wizards.
Some of the guys at Adobe mention a couple of weeks ago that the changes to the SDK should be fairly moderate from now on which also means the issues experienced when updating the SDK should start to stabilize(mind you it seems the progress of the sdk went dark(code freeze) a week ago which could be an indication of some more heavy duty changes coming.)
At the end of the day wizards may work reasonably well on code that doesn't deviate from expected coding practises but you can't beat manual conversion changes for knowing how, where and why code has changed, this becomes rather handy if the behaviour of your masterpiece suddenly changes after a conversion.
One way of keeping in the loop with the SDK is to use svn versions rather than the builds and follow the versioning logs that comes with it. I update a couple of times a week(its only 6-7 minutes to compile and test the SDK) then look at compare changes in the code if the updates are more than bug fixes. Sifting through the code changes is a big part of my own way of familiarisation with the SDK.
In my opinion the answer is to have a MIgration Assistant / Wizard
that provides you a list of precise changes made to your code either
during or after the migration. That way, you can monitor (and approve)
any changes before they happen and have the ability to go line by line
through each change made to FB3 code.