Quality Portal and Tokyo Release 1

Posted by on in Tutorial

The RAD Studio 10.2.1 release (earlier this week) was focused on bug fixing. You can find the list of issues that have been addressed at http://edn.embarcadero.com/article/44763. The list includes 186 customer reported issues there were either fixed or cannot be reproduced any more -- so they also got fix, even if "indirectly" (that is, while fixing some related bug). If we include also duplicate items, expected behavior, and issues we decided not to fix (for some reason) or are not applicable any more, the total of Quality Portal bugs closed is 241.

This list of bugs and these counts don't include bugs reported internally and closed. All bugs touched by the release are 402 (including all resolutions). While there are a few relevant issues not handled (and we are evaluating how and when to release a fix for those) and a few only partially done (we opened a Phase 2 bug for Android performance) a lot if the issues that were resolved improve support of the latest versions of iOS and Xcode, Creators Update (with BPL loading -- more on this in a separate blog post) and Android performance and quality (including the June hot fix).

If we look at the overall status, this is the 30 days status (captured today):

Having pushed out a release, this is very favorable. This is the more realistic 365 days (1 year) status report (this includes bugs only, not feature requests):

What the graph tells is that we need to (literally) double our effort to address bugs and improve the product quality, but both Tokyo and Tokyo Release 1 made a good dent.

The last thing I want to draw your attention to is the list of most voted issues before Release 1:

We did address many of the issues with the highest number of votes in that list:

- Non-functional debugger with Creators Update (which is by itself a Windows issue)

- Android Tokyo app are super slow (data is in the report, but we need to and will do more to address this)

- StringToJString leak

- iOS 10.3

Among those left open, the Chinese VK is very tricky (and regional), IDE DPI awareness is bordering a feature request and something we are making steps towards (we did fix a few more HighDPI VCL issues in Tokyo Release 1) and the C++ linkers issue was addressed, at least in part (we are making more tests and might officially close it).

RAD Studio and Delphi and C++Builder customers keep pushing us to focus more on quality. Over the last couple of years QPS (Quality, Performance, Stability) was and still is today a top priority in our development effort. Some new features like Linux support were really important, therefore we need to keep striking a good balance between features, quality, and bug fixing. But quality is key.

Gold User, Rank: 7, Points: 457
Delphi and RAD Studio Product Manager at Embarcadero.


  • Pat C11795
    Pat C11795 Thursday, 17 August 2017

    I see that a Tokyo update was release a few days ago (10.2.1) and that RSP-18435 was not fixed. I've included sample code that reproduces the problem and I don't see how this could be anything other than a very easy problem to solve. Considering the easy reproducibility, the simplicity of the fix and the catastrophic impact that this issue has on our ability to do our jobs, I'm very disappointed to see that this was not fixed.

    We've been a mostly Delphi shop, and I have been a Delphi evangelist, going all the way back to Delphi 1.0 in the middle 90's. If you can't keep me as a customer, then I believe you're in real trouble. We have no choice but to begin the process of migrating all of our projects to VS, as Delphi is no longer a viable professional development platform. Very disappointing.

  • James H22907
    James H22907 Thursday, 17 August 2017

    It really bodes confidence when you include "issues we decided not to fix" in your count of quality assurance issues closed.

  • Please login first in order for you to submit comments
  • Page :
  • 1

Check out more tips and tricks in this development video: