This was probably the biggest blindspot I had while with Xojo. “Just update the IDE” is easy advice when you’re the one working on it. Back in the real world, changing IDE versions is perilous. The devil you know is better than the devil you don’t. Now my IDE version changes are planned along with my app’s beta periods.
3 Likes
Absolutely: in a complicated project that involves plugins and other third-party code and thousands of users, there are so many moving pieces that even extensive beta testing might not catch edge cases.
Generally, I’ll risk a minor Xojo update for a limited beta testing cycle (e.g. one of my own point updates) but major Xojo updates will coincide with a major version update that will be in beta testing for at least a month.
In this case, I can easily work around the macOS version string issue until Apple release their next update, but in future I’ll be wary of security updates when I’m approaching a major release.
macrumors.com had an article two or three days ago and they talk about this (a) update. I read the article before setting the update.
I am not affected by the update behavior.
I’ve made some changes to AXOVersion to be Ventura compatible
https://www.dropbox.com/s/ef25f0xbqg0bz1o/AXOSVersion.xojo_binary_project?dl=1
I added AXOSVersion.ProductVersionExtra
This bug has reappeared when running apps built with Xojo 2023r1.1 in Japanese versions of macOS 13.3.1 (a). I’ve had 3 reports from Japanese users, and I can reproduce it myself by setting the OS language to Japanese. This line
if system.version >= “11” then → out of bounds error
This is a language-specific bug I reported with 2022r2, and it was fixed then. Now it’s back. I’ve re-opened the old Issue with this information. Although it’s relevant to this thread, I can start a new thread if this regression gets lost in this one.
The Issue is 69743
Here’s the link to the macrumors.com article about Apple Releases Rapid Security Response Updates for iOS 16.4.1 and macOS 13.3.1
dated from Monday May 1, 2023 10:19 am PDT by Juli Clover
If you need a library that includes a similar version function for your apps, I just wrapped up NSProcessInfo as a separate class where you could replace System.Version with ProcessInfo.Version and have your app stop throwing these OutOfBounds exceptions. It also includes a bunch of other process and system related things like getting the processID, username (on mac), hostname, # of processors, etc.
1 Like
Thanks for that. But in my case I have MBS and have switched to SystemInformationMBS, which doesn’t have the system language problem.
1 Like
I was just offering a free alternative.
6 Likes
@Greg_O I know you were, which is why I thanked you. I’m sure others will find it useful.
1 Like
I’m lost for words…
This basically means (or at least very much looks like) that Xojo “fixed” Issue 71254 by doing some (localized) String parsing again. Even though we’ve all pointed out in forum discussion and feedback that’s the wrong way and even pointed to various code bases, references and Apple Documentation doing it the proper way before they’ve shipped this “fix”. 
Let’s just hope that Issue 72640 has made it very clear to Xojo how this needs to be done 
6 Likes
The lack of automated testing on non-english platforms is a concern. Issues in currency, dates and now this (and probably a few others I’ve forgotten). As for not being able to build for legacy editions, I’m amazed the build environments aren’t virtualised and snapshotted after release allowing for instant rebuilds of any legacy edition.
1 Like
It’s not so easy to do that when your entire build system is on macOS.
macOS doesn’t have virtualisation?
Well it does, but not the way you’d want it to be. Without massive amounts of storage imaging the entire build environment would be nearly impossible.
The only thing I can think of that would work is if there was a way to store virtual diffs because Xcode itself is huge. Add in Visual Studio and the storage requirements, even compressed, would most likely be 10GB per image.
All that said, Xojo’s position when I worked there was that the subsequent version was the patch version. We had two times during that 11 years where we tried to build old and new versions simultaneously. It was not fun.
That would be a linked clone.
10GB, is that all? You had me thinking it was something substantial 
I’m assuming from the terminology that you’re thinking of Parallels, but regardless, on Apple Silicon, they use Apple’s hypervisor and in that mode, it doesn’t allow for snapshots or linked clones.
But it has cloning, even without a linked clone, you’re looking at around 150GB worse case with the OS and apps/data, so $10-$15 to put that on an SSD in a draw for emergencies and dupe it online for redundancy. Then once in a blue moon that someone needs an old version rebuilt, slide it in an external dock and boot it up like you just shut it down. Cost to Xojo ~$15 plus time, cost to customer, invaluable, boost to PR, incalculable.
There’s the problem. The amount of time and work that would be involved to set up what you’re proposing just isn’t worth it for “once in a blue moon”
Look, I don’t work there (at Xojo) any more so everything I’m saying here is my opinion, but this gets discussed once every 4 or 5 years when someone needs a patch. Because of how xojo’s licensing model works, the work to create a patched version itself would basically be for free, and the time would be taken away from other things that were already scheduled for the current cycle. And what’s the threshold for patching an old version anyway? If they fix this one, who’s to say that they shouldn’t fix my “very important to me” iOS code signing bug. If they patch 2022r3.2, do they also need to release patched versions of every version that’s affected by the bug? They’ve got several builders, now they’ll need a fiber connection to each one so they can move these images around when “once in a blue moon” they need to move these images around?
Personally I’d rather they spend the money on another engineer or two.
3 Likes
A lot of the the work put in to this would also benefit the current build system add value to the current product and probably free up devs time. Customer retention would increase as would Xojo’s image, Xojo could finally release LTS editions. Licensing could be adapted to account for this LTS support. Xojo is not currently getting any funds from people using old licences as it stands, people sometimes wait months/years for the right update to come along. Want a +1 on your 2022r4.1 release to fix a bug? We’re going to 2022r5 so you’ll need a valid licence even though its not a current release.
As long as the customer is happy don’t mind us that all it took was a few lines of code and a check in on our source control system, the build kicked off and did everything including uploading to CDN and a website update.
It certainly wouldn’t cost a developer or two to implement and run this.
But I digress… I hope they can get to the bottom of this bug.