No 2020 release yet almost 7 months in

[quote=494599:@Norman Palardy]Doesnt solve Alex issue though where the fixes he needs/desires are in a non-release version
I doubt there’s a simple cure like “throw testing open to everyone” that deals with the state things are in today[/quote]

Yes, the last thing I want is an unstable release when I am trying to get a version with important bug fixes so that I can continue to develop code for production.

Well… Code for production, as everybody knows, will be released when ready. Xojo seems not able, for some kind of internal design, to separate the Web 2.0 development from the rest of the fixes, If they could, we could have a kind of 2019r4 labeled as R1 while the current “r1” is not ready.

This is what we are asking for, push a version that has the current fixes and ties us over till there can be a stable release with Web 2.0. I don’t see any huge reasons why something like the navigator scrolling issue or thread.sleep failing should have anything to do with Web 2.0. If they are not able to separate the two then there is some internal flaw with the way it’s being implemented.

I’ve asked things like that before. The simplified answer was kind of “we can’t”.

I think that what you ask would be a kind of “get the 2019r3.1 sources, map all fixes we did in R1, try to reapply there”. This can be done at some extent. But we needed to call the R1 as R2, freeze, and move to this new R1 for a new batch of “development” and tests.

Postgres patches serious bug and security problems up to several previous versions. So it is possible.

[quote=494609:@Rick Araujo]I’ve asked things like that before. The simplified answer was kind of “we can’t”.

I think that what you ask would be a kind of “get the 2019r3.1 sources, map all fixes we did in R1, try to reapply there”. This can be done at some extent. But we needed to call the R1 as R2, freeze, and move to this new R1 for a new batch of “development” and tests.[/quote]
Web 2.0 should have been developed as a separate branch and only merged in when Xojo were confident it wouldn’t delay the rest of the product. That would have still allowed Web 2.0 to be beta tested and for other fixes to be released separately.
We could be sitting here in December still waiting for 2020r1 to be released if Web 2.0 QA keeps going the way it seems to.

This kind of situation is a reason why I think the IDE should be more modular so that out of band fixes can be released more easily.

Oranges are not Bananas. We’re not talking about C source code here. Postgresql is not made with Xojo, and I suspect that the Xojo source is not an organized git tree of known text sources accepting easy diffs and patches using CLI tooling.

Yep. But if this thing was designed to be an intricate monolithic thing (I don’t know), to split things apart now to allow things like that, could need a deep redesign, and a deep redesign means more time doing things that the users can’t “feel” as something tangible and good.

Its not something that users would “feel” immediately but if it provides Xojo Inc some additional flexibility when releasing they would feel it then.

not sure what you mean by “making it modular” ?
you mean making it be all plugins ?

Modular like a project:

#include baseLibs/*
#Include Frameworks/*
#Include IDE/*
#Include Desktop/*
#Include WEB1/*
//#Include WEB2/*

[quote=494626:@Norman Palardy]not sure what you mean by “making it modular” ?
you mean making it be all plugins ?[/quote]
For starters…

  1. Convert as much of the framework as possible to plugins
    (either C based plugins for the C based parts of the framework and the yet to be released Xojo plugin format for the Xojo code parts of the framework).

  2. Separate the project specific parts of the IDE (ie: window / form editors etc…) into their own modules which are loaded at runtime by the IDE.

  3. Separate the IDE, Compiler & Framework to some point so you could potentially take an IDE update without having to update the compiler / framework.

Well… That’s another kind of modular.

Static solves the isolation of development branch problem.

Dynamic creates a solution and a problem.
Solution of being able to change parts as plugins. Problem when mixing incompatible parts.

the point is
if you change source code that affect other parts which was ready before
you get a endless construction area. (see new airport “Berlin Brandenburg” since 2006 … still not open)

[quote=494630:@Kevin Gale]For starters…

  1. Convert as much of the framework as possible to plugins
    (either C based plugins for the C based parts of the framework and the yet to be released Xojo plugin format for the Xojo code parts of the framework).
    [/quote]
    Now all the engineers have to be C++ experts not Xojo experts (they may be both but …)
    They ditched that in 2005/2006 to go the dog food route

In Xojo code ???
Or are we writing C++ again ?

if you poke around the bundle and you’ll be surprised this mostly already exists

Recall they stopped writing the IDE in C++ becuase the writers of the IDE didnt USE the IDE - they used VS, Xcode etc all day every day and so users would see bugs before the engineers
Dogfooding the IDE by writing it using Xojo has meant many more bugs are found early by engineers
I cant tell you how many I found and fixed long before they ever got to alpha and I’m sure that still occurs

We need to change Xojo to enable things like this kind of conditional modularization and design.

sure let me know when WE have the source code for it and are going to redesign the frameworks, compiler and everything will you :P

[quote=494640:@Norman Palardy]Now all the engineers have to be C++ experts not Xojo experts (they may be both but …)
They ditched that in 2005/2006 to go the dog food route

In Xojo code ???
Or are we writing C++ again ?

if you poke around the bundle and you’ll be surprised this mostly already exists

Recall they stopped writing the IDE in C++ becuase the writers of the IDE didnt USE the IDE - they used VS, Xcode etc all day every day and so users would see bugs before the engineers
Dogfooding the IDE by writing it using Xojo has meant many more bugs are found early by engineers
I cant tell you how many I found and fixed long before they ever got to alpha and I’m sure that still occurs[/quote]

re> The framework I meant split it up into as many plugins as possible. I assume the framework is a mix of C & Xojo so the C parts would become C plugins and the Xojo parts would use the new Xojo based plugin format that is on the roadmap somewhere.

re> The IDE. I meant make certain parts of the IDE plugins themselves based on the Xojo code format plugins.

The idea is to try and make more of the IDE interchangeable so that it would be easier to deploy out of band fixes. For example, if there was a bug in the SQLite plugin or the FolderItem plugin make it possible to just release fixes to those plugins before the next major release.

There’s a hard to explain thing here. SQLite ok, there’s an entire engine behind it. FolderItem is just a variant collection of system calls depending on the platform, that should be linked into your executable to get the best results. Having a huge collection of plugins for anything will backfire. It will become a HUGE fat and slow monster. Your deployed apps will become the same ugly thing.

exactly.
there was a bugfix for DateTime.FromString
and in the release app the submenu icon is not displayed at window os^^ (without additional explanation).
i guess in 6 months there was many bugfixes at different locations.