There is this this Blog Post from Xojo: Your Path Forward with API 2.0
Sure, that answers some questions and clears up misconceptions some users might have. It’s a nice and somehow expected marketing move. But let’s look at the “real world”.
While I don’t think that I have misconceptions, I still haven’t found a way to use 2019r2 in a productive way to continue using a hughe project which currently obviously is API 1, and needs to be able to be built with <2019r2 for some time.
Let’s assume, we take the Blog’s approach “Not Upgrading”. Well, a ton of Deprecations which kind of aren’t - because one wants to continue using API 1 for a while. And the approach “Upgrade Incrementally”. Well - where to start…? It’s all mixed, not sorted in Deprecation-Types/Groups. There are no migration helpers available which would quickly and easily replace “safe renamings” (which don’t have a different code execution behavior).
So I understand that one is lost. And 2019r2 doesn’t offer much to help with that.
For that “Transitioning time” there are a couple of Feedback/Feature requests that would help a lot: feedback://showreport?report_id=56856, feedback://showreport?report_id=57885, feedback://showreport?report_id=57888.
Which is also kind of your situation:
Depending on the project/size/resources, it will take months to migrate an existing project. During that time, productive build will be done with <2019r2. But testing/development also needs to use 2019r2+.
And for that situation we don’t really have a good solution. And hardly any “answers” from Xojo. While it kind of “would work”, it’s currently simply a pain to do so, and (from our point of view) quite unproductive.
There are many threads/questions about that already… but no reaction of Xojo until now.
What we are doing (our transition approach):
- Develop and Save the project with 2018r4 (and do productive builds with 2018r4, 2019r1.1)
- occasionally do Beta-builds with 2019r2+. do needed code modifications (e.g. using conditional compiling) in 2018r4. 2019r2+ is just to “open and debug-run / beta-build”.
- there is only API 1 (API 2 just maybe for a couple of bugfixes when building using 2019r2+, using conditional compilation)
- once there will be a time where beta-builds look good for all our BuildTargets with 2019r2+
- only then will the project be saved in 2019r2+ (and: no more going back)
- by then we hope to have a 2020rx, which will be much more useable to transition existing API 1 code… and much of the possible bugs with that “risky release 2019r2” have been uncovered and ironed out.
- if Xojo is still of interest for our future, code might be transitioned piece by piece. but really: why…? API 1 will be around forever (thinking in a software lifespan). more likely is that maybe just new code/projects are going to use API 2.
So from my point of view: Is transition really necessary? A good question, depending on what you’re up to with your project. It may very well not make much sense to do so. And if you’re trying to do that with a hughe project, then 2019r2 is not quite up to the job. Again: just my point of view (looking at our projects). There is still the chance that Xojo listens to what their professional users would like to have (see feature requests above, and quite some more in Feedback). They could support transitioning much better. And by doing that, many more would be willing to start using API 2.
For now, we just have a “first shot” of API 2. That’s looking quite nice. But there is a lot not available that would help to get existing projects transitioned to that future. And again: especially the month-long time where both API 1/2 need to be used within the same code base. For brand new projects, all is looking quite nice. Not so for other situations. Xojo can deliver more - if only they want to.