At one time they had an ALPHA group that would get to try out what you refer to as “incubator” versions
And they had a beta group - now their Testers group
They’ve never really had an LTS version - unless you counted point releases. But even point releases did more than JUST fix bugs
Sorry but Alpha is not even for public showing with hands on. Beta is for showing, testing, hands on. Incubator is the next version as production but in Bugfixing and the LTS Version is the long term support production version. So you have all 2 years an incubator Version and all 4 years a production version. Every year they can give out a beta version with new techs for tryout and for the customers to give their meaning and their Ideas.
I agree, the “madness” is that regardless of new features, you need to upgrade to get your bugs fixed. That’s okay if it would not break other stuff, or even sometimes “re-adding” bugs, which got fixed before. Nothing in software is bug-free. But this release model, which is quite unique in 2022 for a dev tool, is not usable for professional purposes.
During a project you might eagerly wait for a bug fix, but you can’t change if this will add other issues. Catch-22. Not sure if catch-22 is trademarked, other wise it would be a perfect choice for re-branding of Xojo.
You either invest into top notch quality management to avoid such recurring bugs (which is almost impossible to achieve if you are not a very big company), or you need the LTS release model. And LTS doesn’t mean that you earn less as a company. They could say: patch fixing for LTS costs XY EUR / year. That’s not what most companies do, but hey, I think many Xojo ex-users would have supported such a model.
It is more about the quality than the actual price ticket, at least for me. I wasted more money on invested time to find (or fight with) new bugs with every new version than from any price increase or the yearly fee. And yes, that drives you nuts and makes you angry. At least me 
the three channel Model of LTS, incubator and beta building up that chance. Bugfixes can be approved in Beta and on a large base tested in incubator and used in LTX`S for production. Also new features can be tested first in Beta, on a large base in incubator and released in LTS.
Showstoppers can be hot fixed with minor Versions of the LTS what brings the possibility of a correct and production ready state of the software all time.
If they would handle that so I would be possibly even there today. But. Writing Software without a quality Management System and only with one Leader is dangerous all time.
I’ve worked with companies where Alpha was a public thing
BUT - they gave you an ALPHA and said “Any or all off this might get thrown out so be warned”
You didnt use it for “production code”
It was more an early access release to see what things they were thinking of - some, all or none of which might ever get to a beta & other releases
To me that sounds a lot like what you mean by “incubator” ?
Am I misunderstanding ?
Is incubator some where between BETA and RELEASE ???
To me thats just a really long beta - you know - Google style 
How many years was Gmail in “beta” ?
THIS is something that BUG FIX ONLY releases would enable
As it is now with bug fixes & “new features” its a crap shot if an update is even remotely “safe”
A big problem Xojo is going to have in keeping programmers is API 2.0, and especially DesktopControls, which are going to cause problems as I’ve heard that bugs will only be fixed for API 2.0 DesktopControls.
Pre stable release with all features
Which is probably more work for them to pull off given how things work
Yeah I see its in between BETA and RELEASE now
Never done that and not sure it adds much to the process other than making it so they can overlap BETA & INCUBATOR ?
No. Incubator has to be a production ready release what means: it is there for Bugfixings and minor changes in frameworks so people can use it as production ready. Like Java is doing all time. Before the next Release comes (Java 20) there will be an incubator Release. The beta isn’t even public but for the developers and maintainers is. Normal programmers and users will have the access with the incubator which can possibly get changes before Release comes. That makes two incubators where bugs can be found and the lots release can be builded on top of the goodies of two incubators. People building on incubator for their projects can then build, maintain and sell on the its version at least for four years and can see upcoming “walls” of changes in framework and so on in the beta channels and test and implement before release comes in the incubators. So the release cycles of the customers can follow a much more stable process. And the result will contain extremely less Bugs.
There are many of them and at the current rates of fixed and discovered bugs it is unlikely that the bugs of API2 controls will be brought down to a significantly lower level any time soon.
These bugs, in conjunction with the also buggy and incomplete documentation, have the potential to turn away the coveted citizen developer. It takes between 3 months (first doubts) and 6 months (realisation of the full extend of the state of the product). Most of them will walk away silently and those daring to express their concerns will be handled by Xojo Inc…
I know that people new to Xojo have both API1 and API2 controls in their applications. Thanks to the outdated vids on YouTube (‘…we have over 500…’).
I citizen developer still haven’t understood why all this renaming (i.e. ListBox to DesktopListBox) had to happen. The target platform is determined at the time the project file is created and this information is always available when a project file is opened in the IDE.
The entire point of rapid releasing and not providing its is getting new Customers with added functionality. The difference for the customers is significant. While the lots. can stand for years with only minor fixes (Showstoppers and bigger Bugs to fix) you can add to the incubator new functionality which will come up to the next lots version. So the programmers having enough time for implementing and for asking to provide needed functionality to setup their software project proper. So when doing rapid release you release prototypes what we saw with 2020 releases - look on the changes between 2020.1 and the actual release. Many differences. And this problem makes even a newcomer to go.
Because when they first rolled out API 2, it included the event renaming on UI controls. Some of these caused a lot of grief for existing projects, and especially for plugin and/or custom control vendors, with no feasible way to work around them. After much outcry, Xojo relented and reverted the UI event changes. Now, the outcry didn’t convince them that the event renaming was unnecessary and counterproductive, but just that they couldn’t do them with the current controls. So, they had to “create” new controls that wouldn’t cause conflicts.
One thing that surprises me is the number of bugs being reported on the “new” Desktop controls. I thought they were just copies of the existing ones, with the rest of the API 2 changes being applied. But it sounds like they made a lot of other changes also.
IMO, the new desktop controls have caused more fallout and developers leaving (or just not renewing) than anything else before. Between all the years of now useless code examples out there and the increase in bugs, many developers don’t see the value in Xojo anymore.
This is what I realised as the percentage that went into bug/shortcomings workarounds: 50% in projects I developed in my former platform. Way to much, and the major reason why I finally dropped the platform. The goal is to find better.
If this description *
TL;DR: A new JDK Enhancement Proposal (aka JEP 11) introduces playground incubator modules that target experimental features to either be adopted and standardized in the next version or Java, or to otherwise be removed quietly from the JDK. The first feature to be introduced as a part of this project is Java’s HTTP/2 Client.
is correct their just new modules in a different namespace that may or may not get rolled into the JDK
Sounds like a “live beta” of features that could make it to a release - or not
It seems its not a fundamentally different release model - just a different way of packaging things so people clearly know when something is released vs in “incubator” status
No ?
Like this
Xojo could do a little something like this with a module named “Incubator”
Then everything thats “new and not quite finished” goes in there - modules, controls, etc
And you can use it but you know right up front its “experimental” since its name is
Incubator.GridContrl - for instance
And anyone wanting to avoid “experimental” stuff can do so easily
That could help a bit
→ link to ‘Check platform type’ post in TOF
Xojo Inc has no clue how the documentation mess does impact people who try to learn coding in Xojo - or they simply don’t care - or they don’t have the means to fix it.
No Norman in thee to five weeks V20 incubator comes means jdk 20
From top of my head then I do not actually remember any bug in the SDK currently.
And you can return handle to put in truly native control.
Updating naming in the SDK to remove “REAL” would be 100% wasted effort as it would only take valuable time, and brake compatibility for no good reason.
Maybe I need to reword the way that I refer to a bug. Here is one of many examples which I run into:
When working with OpenGL or the Canvas, using a plugin in Windows causes issues when a mouse is moved over the canvas/OpenGL canvas. Whether a callback, polling, or some other event is called, or workarounds in a Plugin. The event fires, and the canvas/OpenGL control does not update. Repeated mouse moving can literally slow the refresh rate to 1 frame per second.
Another issue is interference from the Xojo mouse, where continuous tracking causes slow-downs in refresh rates. Completely bypassing Xojo’s mouse event and implementing my own will remove the issue. An example of this issue is shown with Javier’s How To Speed Timers in Windows - AprendeXojo . Download it and repeatedly move the mouse over the canvas. The refresh numbers are impressive, and the canvas literally stops working until mouse-movement is stopped. Then I attempt to create a workaround and am unable to change the window position. The next workaround is required.
Cannot use glfwSetWindowPos in a GLFW window, and a GetWindowLong Window API must be used instead. Xojo OpenGL does not allow glfwSetWindowPos to work (nothing draws).
You are correct, that I am able to program and use the commands. Unfortunately, the C++ code/Plugin/Declare does not work when viewed visually, possibly due to the way in which Xojo works with windows in Windows?
I can create a program in C++ for a plugin, however the possible implementation of Xojo’s own calls in the background interferes with the use of Canvas and OpenGL.
Don’t get me wrong, completely rewriting all OpenGL, canvas, mouse, and keyboard functions so that they do not interact with a Xojo created window works with a plugin. However, attempting to use native Canvas and OpenGL hooks are incredibly buggy. Maybe this is a better way to describe it?
Edit: I left a reply weeks or months ago, with details to repeat the bug, and have not received any feedback. shrugs. I am writing an updated OpenGL control and starting with OpenGL version 2.1. Performance is MUCH better and significantly less issues. The next step after this would be to work with OpenGL 3.0, then OpenGL 4.0, then Vulkan. Jumping straight to Vulkan with Xojo created too many incompatibilities. I am required to start with OpenGL 2.1 to work around the Xojo graphics/canvas bugs first. Working in baby steps to get to the final Vulkan goal.
Before you go into such venture you need to ask your self some questions.
Is your thing going to work well in Direct2D app (Xojo on Windows are Direct2D apps since somewhere around 2018, Direct2D apps do not play to well with all things and are known to be very slow in graphics).
Is your framework your implementing using any kind of threads. Then you can usually forget it. (Since Xoio just refuses to do proper threads).