1 of 1 people found this helpful
Chris, you were correct in that the build.yml would need to be modified to use the latest gems.
Wehn you create a project, all of the scaffolding is created based on the current Rho installed version, as you update Rho, existing projects will (and should) continue to be based on the install version that was used on creation. Rho does not (nor should it) automatically change all your projects. For some projects, you may want to leave them as is, others you will want to update to the latest install - several ways to do the later: Manually modify the build.yml to point to the latest gem and add any new files that you want to leverage (copy from a new project to the old), you can also create a new project based on the original (give it a new name) it will pull the application over and use the latest build.yml and public.
Some would argue that having an option to automatically re-scaffold a project would be benificial but I would have to say, knowing what you are updating is just as important - thus the methods above would make sense.
A couple of tips on upgrading, I would caution you on having multiple version of rhostudio installed (can get messy), so I would suggest uninstalling the old version (but leave the file structure in place to support old projects) and install a new version in a new directory.
Hope this helps
I agree completely that RhoStudio shouldn't automatically upgrade all your projects and that upgrading manually is the right way. My "issue" is that I have no idea what has changed between the two versions so I don't know what needs updated and what hasn't changed. For example, in the public folder there are a lot of files, but no where is there any list of what changed and what is the same. I could figure it out on my own with a diff but it's not really very user friendly to be given a new version of a tool but no defined way to migrate your project to use it.
I understand you can do the whole "New project from existing source" but that doesn't work very well if you are using source control so it's not a great alternative.
There needs to be some documentation on upgrading existing projects with each major release of Rhodes.
What I have been doing is generating a default project for each version, and then comparing them to see what has changed.
So, I go through the public assets file-by-file to see which ones have changed and how, and then look at the generated code to see what has changed and if there might be any changes I have made to my existing app. This won't necessarily catch everything, though, as I only create a simple default app. (Well, I also add a simple database table.)
Then I decided if I should copy each changed public asset to my project, or otherwise incorporate the changes.
But it's not terribly productive for each of us to be re-inventing the wheel, discovering what has changed individually, when somebody knows but never bothered to document it.
Documentation continues to be Rhodes weakest feature. I know they keep churning out those videos, but videos aren't search-able, and most of us don't have the time for them.
There haven't really been significant changes in generated code, and I wouldn't expect such unless/until there is an update to the included jQuery Mobile version. And I've long ago switched to JQM 1.2. (I think it's time for Rhodes to switch, hint, hint. Until 1.2, I would have recommended sticking with 1.0.1.)