Respect. Many bugs are fixed. That’s really on a good way. 100 Releases more and we’ll have it. 
Important notice:
https://forum.xojo.com/t/is-there-plan-to-move-from-the-legacy-2012-native-sql-client-package-to-the-current-sql-server-odbc-driver/73666
That would be a nice update for them to do since Native is deprecated
I already use MBS so can connect from Mac, Win & Lin already so I dont need this
Is it me, or do most of these look like they’re issues that Xojo created in the last few years. A lot of DesktopControl bugs and documentation fixes. I even see duplicates in the list, such as at least two items are enabling minimum os version for the Mac.
Its not just you
I notice that as well
They say they fixed 100+ bugs
But overall the bug count went UP - not down
But you only know this if you track it and watch these trends
it means that from the day they started working on R4 there were more bugs reported than fixed
This trend has been going on for some time
I’ve watched the open bug # climb slowly from just over 2000 to now consistently around 2100
The number of new bugs outpaces what gets fixed
Thats a problem
Migration to API2 just isn’t finished, not even nearly.
The many erroneous and outdated pieces of documentation are witness to that.
This and the many bugs lurking in API2 stuff makes working with Xojo so frustrating.
Tsck…
I see this positively: This was mostly a bug fix release - something me and others asked for. It was a step in the right direction. Every long journey begins with a small step 
Are they all valid, though? I often see bugs about “Crash near ” filling the list, but I don’t think they are important, as the cause is something else already reported.
These are all closed after 2 weeks when no further evidence is provided, which normally is the case.
That’s right. Let’s hope for the best!
Xojo categorizes them - not us
It’s their evaluation of what is or is not a bug
Not mine
Yes some will get closed as not a bug or not reproducible etc
But the OPEN count is slowly creeping up - not down
It’s what we (as a community) were begging for before, but our wishes went unheard. Bugs fixed, limitations removed, things that are not bugs, but plainly wrong, fixed, performance improvements, etc… Most of what we wanted done at the time, has been auto-closed now, due to being too old…
Now Xojo has to work to try to bring 2.0 ATT back to the same level of stability API 1.0 was at 4 years ago.
This is why a lot of people are frustrated, genuine issues that were present before 2.0 ATT, are still being ignored, as there are too many issues with the “New” shiny.
A lot of the last 3 years seems to have been “churn for the sake of churn”
API 2 - not absolutely necessary and has introduced a whole slew of new bugs. With the Classic API a new person learns the API and its quirks and foibles pretty quickly, learns it once and moves on to bigger better things. Now its confusing since they see old sample code & new code and munge it together and things just dont work
Web 2 - while Web 1 needed an updated just killing Web 1 with no real forward migration path was a bad move. And 3 years later Web 2 is still undergoing heavy fixing and updating. Unfortunately it NEEDS this to get to where it needs to be. Having Web 1 and Web 2 in the IDE supported for some cross over period would have been VERY welcome by many. Web 2 seemed prematurely released.
IDE - while something have improved speed wise I’m seeing people report many of the same old same old issues like huge slow downs. And there are new issues like when refreshes dont refresh the entire text area so what you see ISNT what you’re editing
Documentation - a whole new doc system that was panned by many when released is still undergoing significant revisions. Plus the hundreds of fixes & updates every release, including R4, suggest there’s no automatic process to pull docs from framework code ( something that would aid with accuracy greatly) It seems to be entirely manually updated with every release. And, personally, I still find it not as good at searching as the Wiki.
As for Christians blog post :
Plugin Speed ups - I truly doubt anyone will notice this unless you sit down and write a specific test case to find the tiny speed ups the removal of various checks causes
Web - see my comments above
iOS - since this entire framework is going to be transitioned (?) to “Mobile” when Android arrives any work here is possibly throwaway. This remains to be seen how they manage this.
Windows - not many significant changes for Windows - mostly same old same old since MS supports everything forever so Xojo still cranks out Win32 apps as always. Minor fixes & tweaks
Web was definitely THE big focus winner
Many in the bug list just make me 
I doubt that they build a kitling mobile framework. That they could get more simple. No. They build an Android framework following to the functionality and syntax and also semantic of existing Xojo iOS. Instead they could have been artery and rebuild without forward compatibility for iOS but following to the kitling semantic and syntax. Result WOD be a faster ready much more powerful iOS and Android. This position they didn’t want while realized what pain it is to get over this changes.
That’s the trick behind never getting ready with their android kitling multiplatform mobile solution. Starts to be looking like they have no idea about that.
Looking on kotlin there would be a fast way to simply wrap the language to Xojo and having opened the world for maximum power iOS, android, web and even desktop. This chance they missed in their situation. That makes it even more complex to get ready.
Instead of developing a native desktop GUI framework for kotlin on base of the framework they have…they could do a revolution of the language and even implement tons of technological features.
So the question is what will come out.
That’s interesting. In Java there is JavaDoc, which I think is fantastic and a huge timesaver. Don’t they use something similar with Xojo?
Javadoc has a long tradition. It is a central tool for Java Development. Hence it does not only the Docs for the Java itself but also for the Software and libs you are writing it helps to do docs for every Java lib produced. Means, when and if I am writing a Library in Java for a customer I do the Docs for that lib with Javaadocs automatically. Only a few things more I need to write.
The technology behind is relatively simple but it has to be implemented for the entire Language. And that would be a bit of a problem for the dojo Developers. If they would do the docs would be much more consistent and would have also less errors. But as I said: the implementation is as far as I can see not even in their wishlist.