|
|
||
| Product | |||
| Support | |||
| Everything Else | |||
|
In This Edition: Helix RADE 6.2 Preliminary Release 22: Fixing the fix
For those who haven’t joined us yet, the monthly subscription option came to an end two months ago. But you can still pay $440.00 and get the two remaining updates we plan on releasing through May 31, 2013. As always, you can find all the details of what has changed since the last Preliminary Release in the Preliminary Release 22 Release Notes (updated April 17). As we mentioned in the last edition of The Latest Word, the focus for the April release was on fixing various bugs that were mostly minor annoyances, like a poorly hung painting. The ‘fit and finish’ we strive for was lacking, and we wanted to rectify that. Judging from the immediate feedback we received, it’s clear we should have spent at least another week on those annoyances. Within a day of shipping Preliminary Release 22, we started getting reports of abaci that were failing to produce results, but would then magically start producing results, only to stop again after a simple change. All in all, it seemed like Helix had only a rather tenuous grasp on reality, and was sometimes slipping over into the twilight zone. The Fix, FixedThe problem was this: in order to make Helix more responsive, we don’t always make you wait while a task is completed. Instead, we schedule it for later, when the impact won’t be as bad. This was the mindset behind the requirement that you had to open at least one view in Helix RADE 6.2 before taking a collection back to Helix 6.0 or 6.1. Instead of making you wait during startup, we postponed a critical rebuild of internal structures until it was necessary, which in the case of Helix 6.2 was not until you opened a view. So we addressed that by altering the schedule and making sure it happened during startup. But then we made the fatal error of neglecting to follow the new schedule, and so the rebuilding didn’t happen. Even worse, since we were no longer rebuilding when a view was opened, you could now see abaci that failed to lookup values, defaults that failed to default, and all sorts of incorrect behavior. But it wasn’t that the collection was ‘wrong’ or somehow ‘damaged’ — no, it was simply that some of the internals that make an abacus work were missing. Some folks discovered that switching from Design Mode to User Mode, or that closing and reopening the collection would trigger the rebuild, but that’s not a very intuitive or ‘interactive’ way to build and test your abaci. Anyhow, we’ve now got our schedules straight and this problem should be fully resolved. If you opened your collection with build 5904, you may need to ‘poke’ it — switch back and forth between User Mode & Design Mode, or make a minor modification to an abacus — to get build 5905 to schedule the necessary rebuilding, but once that is done, this issue should quickly fade from memory. Crossed Signals Yield More BenefitsAs we work on each release, we identify the bugs we absolutely want to fix before shipping. Typically the ‘big feature’ for the month is committed a week or two before our shipping date, and our engineers work on the targeted bugs while we pound the new code, looking for new bugs to be fixed. Those get fixed and we deliver a new release. That is a cycle that we have repeated approximately once per month for the last two years. So there are (almost) always bug fixes in the pipeline and, once a new release is out, we promote a few more. There are always bugs to be fixed for the next release. In this way we try to make steady, simultaneous gains on both the bugs and the new features. And so, after the release of build 5904 (on April 11), we flagged a few more bugs as ones to fix before the next release. But then the reports of failing abaci started coming in and we put a halt to the work on the user editor (once again) in order to address this critical issue. It was our plan to fix just this one bug, release an update, and then go back to work on the user editor, saving the bug fixing for the end of the cycle, as per usual. But our signals got crossed and By the time Monday rolled around, our engineers had fixed nearly half a dozen of the bugs we were expecting to fix for the May release. Consequently, build 5905 fixes not just the abacus bug, but five other issues that, while not being show-stoppers, were certainly annoying, judging from the level of chatter we were hearing. (After all, that’s what got them promoted in the first place!) They are these:
That’s five or six additional bug fixes, depending on how you prefer to count them, available to you now, in build 5905. The Best Laid PlansFew users really take advantage of the all the benefits that accrue from being a Europa Pioneer, and we certainly understand that. One of those benefits is the interim updates, which give you access to the latest fixes as soon as they are ready for testing. When a new bug such as this one appears, the fix is typically available in the Interim Builds long before it makes it into an official release. This is only the second time we have chosen to “recall” an official release and replace it with an update, but we felt this bug was too disruptive to leave out there any longer. We realize how annoying and disruptive this process has been. It won’t be long before it ends, mercifully, and we can move ahead to bigger and better things. We want to get as many of you as possible up and running in the new RADE for macOS as we possibly can. On May 31st, the carriage (i.e., the current price structure) turns back into a pumpkin as we pivot toward our future. There is still time to save money, but it is slipping away quickly. And if you have already downloaded Preliminary Release 22 build 5904, please replace it with build 5905 right away; you’ll be glad you did. * All prices are stated in US Dollars. |
|||
17 April 2013 — An update to the twenty-second Preliminary Release of Helix RADE 6.2 is available today. The ‘5904’ build has been updated to ‘5905’ and you can use the same download links to get this update to Preliminary Release 22.