Change is expected and is necessary for improvement. After being away from Xojo development for 4+ years I am seeing change in the Xojo language. Before I stopped development I had converted my two big projects to use the new framework and text vs string to future proof them and put them to bed. Xojo provided compelling reasons for framework changes which I bought into. Now it seems that both fell out of favor due to I am assuming the lack of uptake from users and Xojo itself in its own projects (IDE etc.). Now we have API 2.0 which has the compelling reason of consistency. No one can argue that consistency is something a language should have. But along with change, a discussion of commitment should happen. From what I have read on the blog and forum discussions I have seen statements about not worrying about existing code breaking and that you have years to convert to API 2.0. Seems reasonable. But what about commitment? Xojo has stated that they are not converting (or maybe a minimal amount) code to API 2.0 at this time since it such a large endeavor to convert such a large project as the IDE. This is where I say, not this time. I have no intent to convert to API 2.0 until Xojo shows some commitment on their part. Show us that you have (or at least plan to) convert code and there is no turning back. Eat your own dog food as the saying goes. It is not fair to keep adding (and removing) disrupting changes if you are not suffering along with us. Converting to API 2.0 is a big deal for us to.
very well stated, and probably agreed with by unfortuantly way too many developers around here.
With the release of Catalina 10.15.1, the SelectColor issue in 2019r1.1 built apps is resolved, and that was the only issue holding me back from releasing with r1.1. So I’ve just gone back to my r1.1 saved code-base and recompiled with same and I am releasing.
No bugs. Works great.
I did a lot of work to get the apps running with 2019r2, but I don’t think that work was wasted. I learned a lot for future attempts with API2.0. No loss, other than some hair while fielding emails from my clients.
One thing that keeps getting left out in these statements is the details of why we are transitioning over time. The simple facts of the matter are that:
A. As Geoff stated in his blog post and his sessions at the MBS conference, the amount of time to convert a project the size of the IDE to API 2.0 could easily be measured in weeks, months or years.
B. Going through every little bit of code and changing it, just for the sake to the new API will introduce subtle bugs in existing code that we know already works a certain way.
Weve also stated that all new development will use API 2.0. The work thats going on now for new features in upcoming versions of the IDE since 2019r2 was released all uses API 2.0 when its usage wont be confusing in the context in which its being used.
We also have plans to convert very specific parts of the IDE and framework when there are obvious performance advantages. For instance, the Web Framework has a heavy use of JSON and will be converted to use the new methods.
FWIW, in addition to three large projects written in Xojo (IDE, Feedback and an internal one), we also have about 40 little utilities of various sizes and project types (Console, Desktop, iOS, and Web). Theyre all getting this same code treatment, and we have run into bugs and other complications because of them, many of which were fixed before they made it out into the wild.
Do you have any code that needs to work in 2019r2 and older editions?
Pretty sure the answer is 0% which is why they dont see the same issues moving to a new version that we do 
[quote=461184:@Greg O’Lone]One thing that keeps getting left out in these statements is the details of why we are transitioning over time. The simple facts of the matter are that:
A. As Geoff stated in his blog post and his sessions at the MBS conference, the amount of time to convert a project the size of the IDE to API 2.0 could easily be measured in weeks, months or years.
B. Going through every little bit of code and changing it, just for the sake to the new API will introduce subtle bugs in existing code that we know already works a certain way. [/quote]
You’ve just highlighted the reason why API v2 is generally a bad idea. Lots of time spent changing existing code and introducing bugs for zero benefit. I’m sure Xojo Inc. could have spent all of this time and effort addressing real problems and not inventing new ones.
Here is a good exercise for Xojo Engineers:
Go ahead and…
- Open all your Projects in 2019r2
- Analyze Project (to “touch” every project item | or just add some comments in every project item to “not break behavior”)
- Save in 2019r2
- Look at the Diffs (which is what we are doing, since we want “clean code” checked in while still building productively with 2019r1.1)
- Open the projects in 2019r1.1 and see if they still behave as before (which they should, since you haven’t modified/added new functionality in 2019r2)
- fix all the bugs immediately for 2019r2.1… you will find them, such as: <https://xojo.com/issue/58093>
That would be both “eating you own dogfood” AND experiencing what we are going through.
@Jürg Otter
you know they won’t do that…
It would be too much work and take too much time…
somethat that obviously the rest of us have plenty of.
We use Xojo in ways Xojo doesn’t
They never go back to an older version.
There’s no need for them to do this.
So while users like yourself, and many others, do for all kinds of reasons, like supporting your users who use older versions of Windows, Linux or macOS, Xojo has no need to do this and so never experiences that issue.
This is the difference between eating your own dog food and understanding the dog food your users eat
It’s not the same food