One thing which could be an issue for a few years is needing to use different xojo versions depending on platform or OS version…
While ideally it would never happen, in the real world sometime a new method works well on one platform or OS version but is problematic on another (and this may increase with more use of OS APIs under the hood - particularly on the Mac with its rapidAPI changes) so we may find we need to keep code compatible with classic code or easily go back to the old way so we can move between IDE versions…
In those cases we may want to make sure we are NOT using API 2.0 calls to maintain backward compatibility, I wonder if that could be an analyze option - indicating lines out where API 2.0 IS being used and maybe mentioning the old method.
Also for analyze project for both this and deprecated items, would it be possible to have a a double click (or contextual menu choice) on the item take us to the relevant doc page in the help?
Though I never embraced Xojo Core in my projects, one of the sentiments that I had during the conference was API 2.0 would be the way forward while original framework / core framework could be used, it would not be updated unless there was a serious bug. Also, once you move to later releases of Xojo, it wont be possible to bring your project back to earlier versions.
Again, it makes sense, we just have to embrace the change like we do with Apple products.
[quote=435992:@Rich Hatfield]Though I never embraced Xojo Core in my projects, one of the sentiments that I had during the conference was API 2.0 would be the way forward while original framework / core framework could be used, it would not be updated unless there was a serious bug. Also, once you move to later releases of Xojo, it wont be possible to bring your project back to earlier versions.
Again, it makes sense, we just have to embrace the change like we do with Apple products.[/quote]
For the long run yes… but the transition period is the issue (though less so than with Xojo Core), because of the time it takes for new things to become stable with good performance across all the relevant platforms/OS versions supported.
Over the years I have learned to be weary of adopting newly implemented Xojo features because of potential bugs (when there is a significant amount of new code, there will likely will be some bugs initially that were missed) as well as performance issues (which may be platform specific) …
It often takes several releases before things settle down.
I usually like to use the current version if possible, but until I know for sure the new features are OK, keeping code compatible with prior versions, even with new code, IMO is a good idea. Been burnt by not doing that in the past!
Yes and understood. However, you will need to be weary about using newest version with current projects if your plan is to go back to prior versions. I believe there will be no undo once you go with the latest. Only way I can see around this is maintain 2 code bases for the same product.
[quote=435997:@Karen Atkocius]That question was asked in the video… At least initially going forward, from what was said in the video, that will not be the case.
Maybe I am remembering it differently, but I believe that was a reference between converting your code from the old framework / core to API 2.0. That did not reference saving projects in the new version of xojo and then being able to open them up in prior versions.
you need to watch Web Framework 2.0 presentation from greg. around 17:15 he talks about project transitions where he discusses one way operations and that your project could have code updated to the new data types in api 2.0 once you agree to convert your project.
this is why once you convert your project, it will probably break on prior versions.
right, so if i have a web project that is converted to the new framework then i wouldn’t be able to go back to previous xojo version using the converted project. the only way to go back would be to fork the main code and maintain two projects.
What made me smile: First we learn about Dim becoming Var in API 2.0. Then the Database using Exceptions. And look at the example code for that in API 2.0 - all is using the old Dim
Just before that they want to have all example code embracing API 2.0.
Not an issue - it just made me smile