I even suggested that if the app is large but only likely to be in use for a few more years, it might not be worth converting. That’s certainly something users should consider.
Software development projects tend to follow the same make up as many projects do where most are small, fewer are medium and even fewer are quite large.
We see this when we talk to users about their projects, we see it in the questions that come in to tech support, etc.
That doesn’t mean large projects are any less important. It’s just that they are a smaller subset of the total. I’m sure that’s true for most development tools.
Keep in mind that we have many large Xojo projects here at Xojo, Inc., including the IDE and much of the frameworks, as well as many internal projects such as our CRM and Feedback system.
So the ability to use Xojo for large projects is critical for us as well.
1 Like
My opinion is, that you can’t really compare internal projects with professional ones, which you ship to your users. Internal software doesn’t has to be so extremly stable as your real end-user software.
Sure, the IDE is your public project. But that is a desktop app, which you keep supported. Web 1.0 projects aren’t.
Imagine if the IDE were a Web 1.0 project, which has the following properties:
- Doesn’t come to it’s end in the next forseeable future
- Contains bugs or weaknesses, which makes you super unproductive at some times
- Could stop working in one or two OS updates
- Converting to Web 2.0 - you know better, what would it cost you?
Honest question: what would you do? What would you expect from your vendor? Would you convert the IDE, rewrite it entirely or would you beg your vendor, that he maybe changes his opinions.
I know. It’s more a technical thing than a opinion. And I already resignated, but maybe atleast you can give us better advices?!
4 Likes
We deal with this on a regular basis. We use many different technologies, libraries, frameworks, operating systems and more. There’s regularly something that is no longer supported, no longer compatible, etc. As just one example, when Apple announced Carbon, they said it would be a first class citizen. Years later they depreciated it, requiring us to write an entirely new MacOS framework based upon Cocoa. After many years the web had changed so much that it wasn’t practical to upgrade the existing framework so we wrote a new one. Most of the time we have insulated you from these changes but we can’t always.
@Geoff_Perlman whilst still aligned with thread topic - Xojo still needs to fix breaks with the old framework. In my exampke - the localisation issue.
From what I understand (and initi al tests) R 》19r1.1 broke web localisation. That us a key part of my marketing strategy. My web app is built on 3.1.
What am I supposed to do ? Revert to 1.1 ?
Should fix stuff new releases have broken…
Have you filed a bug report about this? I’m looking in Feedback and it doesn’t appear anyone has ever filed one.
Yes - it is 58058. Here is the forum thread also: Web App language problem - #3 by SteveP.
As you will see, it is indeed fixed in 2020R1 but (for me and others) makes staying on the suggested fallback of 19r3.1 or 3.2 not possible therefore (and I haven’t even trawled over the release notes to determine an implication) falling back further to 19r1.1 IF localisation is important until such time that the conversion to 2.0 is practical.
Steve
EDIT: Thought I did a ‘Reply To’ but apparently not, so tagging you @Geoff_Perlman instead
3 Likes
I’ve the feeling there are too many open cases in Feedback so searching there isn’t so easy.
4 Likes
The entire Diskussion will get an end when xojo is granting maintenance for 2019 Version until 2020 is really ready and production ready what I guess will be with upcoming of 2020R3.0 like it was with 2019 Version. But. There was’nt a big break between 2018 and 2019 like learning to wrote a new language, most deprecated features where still there and available. So, in my view, there is only one thing needed:
Xojo 2019 is under maintenance until 2020Rx is in full production ready circumstances with all features what are supposed to be in 2020.
When we have all the features we can decide if there will be a way to rewrite / convert or not. If not we will have to change the platform, if than we will to try rewriting / converting.
All different decisions will press professional developers witch are under control of government authorities to change the plattform cause it is not possible to do different. It is not a wand to have it is a have to have cause you will not be able to release for a longer time when the Software is out of maintenance. At this point we all would have to write to the point live-cycle of the software is not being updated in future even if there are bugs that will be there.
If you write that cause youi have no chance: the new version has not the features to write a future version … there will be the end of your complete conformity to all software rules. The end of your product.
2 Likes
Plus restart IDE every half hour because typing is sloooooow.
Fixes to this should be back ported.
4 Likes
The IDE on Linux should still be be supported because the OS hasn’t changed that much. If you concede Web 1 apps might still have 5 years left in them, it’s inconceivable that their development will freeze for that time. Therefore the issues with the IDE should be fixed.
2 Likes
Plus…
use the binary project file format,
boot in the internal SSD,
never run more than the Xojo application,
always have 40 or 50GB as free part of the HD,
Set the Plane mode to OFF (even on macOS),
reboot every days,
Do not add a 1024 x 1024 icon in the project unless you are ready to release the application,
etc.
1 Like
Another reason why we MUST have an update to 2019r3.x is because in-built help on Linux IDE doesn’t work and the help seems to be changing on Xojo’s web site for Web 2.0. Sometimes I get stuck when I don’t have internet already which is really annoying and should be fixed. (Of course if the documentation disappears in favour of Web 2 then we are in trouble because for Linux IDE there will be none.)
Like you see @Geoff_Perlman there are many reasons from others and also mine. It is a problem to stop supporting and maintaining of the only possible production ready and believe that the users are not in such high level developing that they simply can switch to 2020 with their web projects. But it is not like you think. Xojo has a broad community of developers and all of them are in the need that the production level ide is maintained, not deprecated and available.
1 Like
From an Movie Original Soundtrack (France):
“Dreams are my reality”
That’s in a nutshell why users wanted a bug fix release only. But Xojo’s PR driven release model had nailed Web 2 onto his sails so instead of having 2020R1 with bug fixes and an improved listbox header in Mai we had to wait for Web 2 …
Xojo REALLY needs to change to a “new feature then a few bug fix releases” model to get more stability and usability.
2 Likes
Maybe, but that idea doesn’t solve the present problem.
1 Like
Btw the logic behind the Rapid Release Model is seriously flawed:
“Users want new features faster. Nobody buys a release for bug fixes”.
Users buy a license because Xojo does what they need - then you already have them for a year. So now make their experience better. Improve the product by fixing the annoyances.
9 to 12 months later when they are good and ready … THEN release new features.
Developers might WANT new features, but what they NEED is stability and reliability. After all, their livelihood DEPENDS on the tool they are using.
2 Likes
This is a logic error because not everyone buys at the same time.
Anyway, it doesn’t solve the present problem which is pressing and real since the online help for Linux IDE 2019r3.x is being depreciated so that things are harder to find and the local help doesn’t work!
1 Like
They don’t have to.
Like with my computers operating system, I never jump on the newest version. I wait a few dot releases for things to become settled, and usually install it at around version .3 or .4 when its stable. By version .6 or .8 they tend to be VERY stable.
There is a reason why MacOS X 10.6.8 Snow Leopard has cult status.
The difference is simply whether you end up with a stable and usable release each year, or a constant beta quality product that traps you in impossible decisions.
Your case in point: if 2020R1 had come out in May without Web 2 but the bug and documentation fixes you need, would you have upgraded?
Would you not want a stable and usable release? And not having to decide between which version to use for what project because of bugs that you can’t work around?