Wanted: Xojo ‘Snow Leopard’ Release

Ever since Xojo adopted the Rapid Release Model (RRM) there have been critics. The critics said that it was leading to a perpetual state of beta software. I’ve always felt that the assessment was a little too harsh but I have definitely come around to that thinking.

In my many years of Xojo consulting I played the “what version of Xojo do I dare use for this client?” For a few years the Windows drawing issues meant that one of the early Xojo 2017 releases was my gold standard. And then finally Xojo 2019 R1.1 was my gold standard for all projects. I haven’t fully tested it but I’m really hoping (and frankly needing) that Xojo 2020 R1.1 eventually becomes my new gold standard.

The shear number of new things between 2019 R1.1 and 2020 R1.1 is staggering. People are still finding bugs in API 2.0 that haven’t been addressed. And yet Xojo is on their way to major updates to iOS and adding Android, adding Helpers and who knows what else.

Feedback is broken for intents and purposes. The top 20 list is all feature requests with the exception of two items that are most definitely bug reports. One is a Web 1.0 WebListbox issue that might as well be closed now and the other is a Xojo framework issue with ParseJSON and that might as well be closed now too with API 2.0 out. Everything else on that list would be freaking awesome, but only if the rest of Xojo was more stable and less buggy.

Monday a Feedback Report 61895 titled “Do a Xojo ‘Snow Leopard’ version that focuses solely on bug fixes and performance improvements. For those that don’t know the reference, Apple released a version of Mac OS X named Snow Leopard that did very little in the way of new features but worked on stability, speed, and bug fixes. It’s still considered one of the better OS’s that Apple ever made. I think in large part because they kept their promise of fixing stuff and not adding major new features.

Anyway, back to our Feedback Report. Within hours it had climbed to number 13 on the top 20 list and then was closed by Geoff as “Not Actionable’. This seems intentionally obtuse on his part because I know several long-term developers that have advocated for such a release for a long time. I even wrote about it in June of 2018 https://www.bkeeneybriefs.com/2018/06/xojo-and-the-rapid-release-model/. So this is not a new idea.

Look, I’m a developer, too. Working on bugs is no fun (especially for obscure ones) so I get, from a developers perspective, that new features are way more fun and exciting. But just once I’d love to get a Xojo that didn’t have a bunch of new classes, API, targets, etc. just so that the existing things we have becomes better, more stable, less error prone, and an IDE that is faster and more efficient.

Is this idea perfect? Oh heck no. I realize that bug fix releases might not attract new users. But it does make people like me happier and a happier Xojo developer is a good thing. I think marketing should be able to make hay with the sunshine that results from a better product.

Is that too much to ask?

17 thoughts on “Wanted: Xojo ‘Snow Leopard’ Release

  1. If they did a “Snow Leopard” release, I might be willing to cough up for another licence. Meantime 2019r1.1, as you pointed out, is fairly stable, and relatively bug-free.

  2. The complete discussion about solving the Feedback problem went exactly …. nowhere. According to Geoff there is no problem, hence there is no problem to solve.

    We all know that fixing bugs is boring.

    The other day I wanted to rename an interface. Crash. It took 3 crashes until I remembered that removing an interface makes a hard crash. Something that should have been a click was 10 minutes or more.

    Every time I edit a control in window the control loses focus. Change left, focus lost, change right, focus lost. This is so annoying.

    And let’s not talk about the surely hundreds or thousands of obsolete bugs.

  3. Ideally, it wouldn’t be a one time deal. Commit to three releases a year. Two with features and bug fixes, then wrap up the year with release 3 that focuses solely on bugs. A yearly snow leopard that can be counted on just in time for Xmas

    • That’s close to what Microsoft is now doing with Windows 10: One feature release and one bug-fix/performance improvement/stability release per year. And truth be told, that cycle is still too fast for an operating system – the Ubuntu LTS release cycle, where you only get one stable, long term support release every two years, is the better approach. You can update every two years, but you can also stay on your version for five years (or even ten years, if you buy the support package).

      Following discussions like this about a supposedly professional development environment and framework, however, will push people away that are in the middle of a decision making process: You don’t want to invest in a product that very obviously is a buggy, unstable mess. It also firmly cements a gut feeling that many, many people have: Don’t use development tools from small companies. Not only can their products disappear over night, in all likelihood they also do not have the manpower and resources to fix and support their product. There is a real danger in using tools like Xojo, B4X, PureBasic, PowerBasic or BlitzMax/Monkey X/Monkey 2 – you name it. The latter has already “disappeared” into “open source” – and the BlitzMax programming language itself was vastly superior to Xojos archaic Visual Basic style. Still, the company died and the main developer also went back into the 9-5 worker class like the rest of us.

      If it’s (product) stability you’re after, you need to use tools with large communities and languages that have independent standards committees like Python, C or C++. Even Java and C# are safe bets, because there are many different implementations available; these tools won’t go away and you don’t have to rely on a small company to keep them alive. Even Lazarus/Free Pascal – a supposedly dead language – has more following and more developers than the commercial products Xojo and B4X.

    • Given that folks have recently been reaching out to ask me compiler questions, I was curious what the report might be, so I clicked the link (in Chrome) and got a completely blank page titled “Untitled”. View Page Source is disabled, so I guess there’s literally no content being served?

      I can understand “we don’t let people without accounts view bug reports” (though I don’t agree with the approach, personally), but holy wow is this taking it to an unprofessional level. What’s worse, given all the public discussions about correctness issues with the product, I honestly can’t tell whether this was a design mistake where someone failed at the basics of user experience for the feedback system or whether this is a bug in the web product offerings.

        • Wow. Thank you for the explanation; what an extraordinarily awful design for a feedback application. Glad I don’t have to try to support that in a corporate setting where someone actually cares about security.

      • The text of that case is quite simple and is as follows :

        Due to the way feedback works I cannot search for all reproducible cases – so theres no way I can give a detailed list
        My request is for Xojo to take the 200 reproducible cases with the most points and fix those
        Since this is likely to ALL be bug reports I would hope that would knock a significant number off the list or reproducible cases

  4. I would really like to see an announcement by Xojo Inc. of some improvements to come into implementation soon.

    for every release cycle, Xojo Inc. reviews top 100 list of bugs. This may include bugs inserted as features like case 36888, which could have been entered as a bug not handling UInt data types properly in variant.
    Xojo Inc. picks 20 of those cases to be handled in the release. Not all may be finished, so aim for 10 to ship with fixed state.

    Now Feedback points make sense, because a case getting a few points may not show in top 20 list, but may still get in the top 100 bug list.

    And of course make the list of 20 picked items visible, e.g. as list in Feedback app. And later announce in blog, which 10 items made it as items reported by users.

  5. Xojo clearly and demonstrably fixes a lot of bugs in each release. I think we all just want to see a release every now and then (once a year?) with zero new features and nothing but bug fixes. It’s a nebulous area, to be sure, since some bug fixes will be a major enhancement and others will be nice to have and while others most of us will never notice it.

    Xojo is a user of their own product and they have been for years. If a bug affects them it gets fixed sooner rather than later. But you can tell that they don’t do day-to-day database work, or generate reports, or use RTF or some of the other areas of the product. Their use of the product is different than ours which was why I was always a proponent of them doing consulting because they’d change some thing to accommodate their consultants to make their lives easier and get projects done faster.

    • They’re too small to do consulting. If they would, a) they wouldn’t have to sell Xojo anymore to anybody, because that would be their secret weapon and b) they wouldn’t have the time anymore to properly develop and support the development environment and the programming language.

      I’ve worked for a small company like that twenty years ago; we had an excellent programming language that we sold, but not even remotely enough man power to implement all the features that we wanted to implement in an acceptable time window. We also had to provide support to our users – and even without consulting, that already filled three fulltime positions in a team of ten full-time developers. Does Xojo even have ten developers? I doubt it.

      Looking bad at my own experience at that mentioned company, I believe that we would have been more successful as a business if we had focused on consulting — but in a slightly different way than you probably suggest. I wouldn’t have sold the product to others. I would have occupied the entire market niche and used the product exclusively for our own market niche: Back then, that was bringing legacy Clipper DOS-applications to the 32-Bit OS/2 and Windows world. I’m pretty sure that many of our customers were making more money by using our product for exactly that purpose than we did with developing and selling the product to them.

      Another thought: Would you really liked it if Xojo were to cannibalize its own customers and taking away business from –you– ? That was the main argument why we didn’t go into that market back in the day. Yes, from a selfish perspective we probably should have, but this is not how you build an ecosystem.

  6. It’s not a problem if new features come with lots of bug fixes. The issue is that the bugs are not being fixed.The reason for the ‘bug fix release’ ask is to get the bug fixed. Based on Geoff’s behavior that won’t happen.

  7. What is the point of only bug fix release as they fix 100 bugs and introduce another 100 in the same release

    • The idea being that many (most?) of the new bugs introduced in a new release are part of new features or major functionality changes. Obviously it’s not always the case but bug fixes tend to be very targeted with the edge cases defined fairly well.

      For example, if I have a hierarchical Listbox on a Container Control (I have one of these somewhere in Feedback) then that should be a relatively easy bug fix and easy to verify that it’s fixed and pretty easy to see if it works in normal usage too.

Comments are closed.