1504: Addressed issues reading scripts containing Japanese text. This change addresses the issue reported in this forum post.
1503: Script Debugger 8 was incorrectly looking for software updates through the Script Debugger 7 appcast. Script Debugger 8 now looks for software updates through its own app-cast.
1501: Resolved a crash that occurs when opening compiled scripts created with the Script Editor.
Without reading any of the notes I tried to install downloaded it and the icon had an X on it saying it required Mac OS 13.
So I downloaded on my laptop, which has MacOS13, and when there was no X on the icon but when I tried to install I got an alert saying it needs MacOS14.
So, if I may suggest, the error message that displays on MacOS11 should indicate it requires MacOS14
(I’ll have to install it on my wife’s laptop to use it)
For technical reasons we build against the macOS 10.13 SDK which is perhaps why the app icon was not shown as damaged, but when launched Script Debugger reports that it needs 10.14 or later to operate.
I just discovered and took a look at SD8 and by golly it’s awesome. Addresses a lot of niggling things I’ve been bouncing around in my head trying to find the time to post about. And then some. So, thanks for your efforts!
Consequently, I’m really really keen to upgrade! Take my money. And I suspect I’m not the only one. I’d pay for the beta as it is, even with bugs or whatever, except for this one major issue:
Please be aware that Script Debugger 8 introduces significant changes to the way documents are saved, particularly when debugging is enabled. We strongly recommend that you use Script Debugger 8 on copies of important documents to ensure you can recover if your documents become damaged.
So, burning question (and apologies if this is answered somewhere else, but if it is I can’t find it – please feel free to point me there if it exists):
Any timeline on SD8 release? Or if nothing else, any timeline on when a “safe, won’t damage your documents” SD8 might be available, even if you’re still ironing out other bugs?
Not to try to tell you how to do your job or anything, but an idea: Perhaps there’s room to focus your efforts first and foremost on that one bit of functionality (making the file format safe), and then release a public beta that won’t damage our files even if there are still other issues in it. Just a thought.
Needless to say, SD8 is awesome. Hoping we can use it in production soon. If nothing else, can you comment on any kind of timeline?
Now that Script Debugger 8 beta testing has begun, we will provide a free upgrade to Script Debugger 8 for anyone purchasing Script Debugger 7 after Jan 11, 2021. You can purchase Script Debugger 7 now with the knowledge that Script Debugger 8 will be available to you now and when its released.
Out of responsibility to our customers, we’ll probably always indicate that people should not use Beta software with production data. We just don’t want anyone to loose important code because of a Script Debugger beta failure. The nature of testing is that you can never predict when something is completely stable. That said, we would expect document save and read related issues will be found and fixed fairly quickly as these are central features of Script Debugger that are used heavily.
Hi Mark. Thanks for that. Perhaps I should have clarified, I’ve already bought SD7. I think it was last year not 2019, so the news that I’ll get 8 for free is nice. I’d still pay for 8 even if that wasn’t the case, given how much good new stuff is in it.
And ok, I hear you on the warning and responsibility to your customers. Fair enough. So probably can’t use it in production until it’s out of beta… And so, do you have any timeline (even if only a vague idea) of when that will be?
I misspoke in my reply, I meant to say January 11, 2021. However we will also provide free upgrades from Script Debugger 7 going back 6 months from the date Script Debugger 8 is released. If you fall outside this window, the upgrade will be discounted 50%.
That’s probably best. As with all beta testing, never expose production data to non-release versions of software. If the proper care is taken to ensure you have good backups, you can safely experiment with Script Debugger 8.
We want to be done as quickly as we can, but it will be ready when its ready. Because of the significant file save/read changes in SD 8, we need to be especially careful. Ideally, we’ll be done by the end of February but I’m not making any promises.
Hi Mark, Thanks for all the extra info. No problem with the upgrade pricing, of course. I think what you’ve presented there is more than fair. And thanks for the potential timeline… won’t hold you to anything, but good to have an idea. And I’m happy to hear it’s getting pretty close!
When opening SD8 for the first time, it complains about no “default template script” being found and suggests that I chose “another default template using the General preference panel”. There is an OK button, and I’d expect it to send me to that panel but it does nothing. That’s 2 UX issues, and 1 UI issue. But I’m not sure what to do about all that.
Thanks, we have a bug on the issue. The problem is that we’re copying across the name of your custom default template from version 7, but not the template itself.
And I suspect I’m not the only one.