What it is
A technology roadmap is a plan that matches short-term and long-term goals with specific technology solutions to help meet those goals.Disclaimer: This information describes EurekaLog's general direction at this time, and should not be relied on in making a licensing decision. The future development, release, pricing and timing of features and functionality remains at our sole discretion and may be changed at any time without notice.
What is current EurekaLog status
EurekaLog 7 is our current product, which is under active developing and support. EurekaLog 7 was released about 1 year ago as a replacement for the previous version (EurekaLog 6). While EurekaLog 6 was a great product, but its internal structure prevented major changes - such as bringing new major features and going cross-platform. Therefore, our primary goal for EurekaLog 7 was refactoring old code into more flexible and modular system, which should allow us to add new features and support for new platforms more easily.Thus, EurekaLog 7 introduced support for native Unicode and Win64 platform, as well as large amount of your suggestions and improvements. There were problems, of course.
First, while we tried to keep backward compatibility as much as we could, but this was not always possible. There are limits for retaining backward compatibility. Existing EurekaLog users try to port/upgrade their applications from EurekaLog 6 to EurekaLog 7. And they encounter problems due to these limitations. Project options, source code, behaviour changes - some of these may need adapdation for older projects. Still some projects may be upgraded very easily, while some other require more changes.
Second, EurekaLog 7 has to change some "play rules" because of the Unicode/Win64 support1 (see notes for more info). Existing customers of EurekaLog 6 may see a behaviour of EurekaLog 7 that is different from behaviour of EurekaLog 6, and they consider this as a bug - not realizing that this may be a limitation of technology/platform support. Code or options adaptation may be required to mitigate this issues. We greatly expanded our documentation to cover many new topics. For example, there were sections added: configurations, DLLs, external tools (protectors, etc.), multi-threading, etc.
Third, there always be problems for such major changes in code base. While we use automatic testing and do beta-testing2 (see notes for more info) - there still are not-yet-found bugs in stable releases. So, our next concern was improving stability and reliability of EurekaLog. EurekaLog 7.0.07 is our latest stable release. It fixes a lot of found problems. And we feel that most critical issues were fixed. Check out our change log to see all fixes!
Immediate plans
We will continue to improve and bug-fixing EurekaLog. Currently, we think that most problamatic part is C++ Builder support, which should be addressed soon. We want EurekaLog 7 to be rock-stable, thus we do as much as we can to keep it bug free. New features may be added as well, EurekaLog 7 is expected to be more changeable than EurekaLog 6. For example, there already were many little and big features added since initial (7.0.00) release. Personally, when talking about major new features since initial release - I would note support for JIRA, non-Embarcadero compilers (and other external tools), 64-bit disassembler, and "Deferred call stacks" option. Of course, there were many less significant features added. See our change log for a complete set of new features!Our forums were recently changed. Now "Suggestions" forum is sorted by top views, so now we all can easily track most-wanted features. Both "Suggestions" and "Bugs" forums now have "Closed" sub-forums. We will move completed issues to "closed" sections. If you had posted a suggestion - check if it is still open. Most likely it was already completed - which means your topic was moved to "closed" and we had given the explanation where to look/how to perform for the desired behaviour. We may close some features as "won't do" verdict - due to technical limitations or other reasons. If you are not satisfied with our resolution on your suggestion - please feel free to re-port it again, appending explanation about how you think your suggestion was not resolved. The same holds true for bug reports, of course. Suggestions and bug reports in normal forum are considered to be "active". This means we either are working on these or put it on hold (but not rejected/closed).
Our web-site now have new section dedicated to you as EurekaLog user. There we will publish contributions from all of our customers. There you can find code samples, plugins, localizations (translations), tools, etc. So far there are not a huge amount of things to see, but this list will be expanded over time. For example, we hope to publish a detailed memory analyzer/dumper from Alexandr Bagel (Rouse_) (link points to Russian blog post).
Feel free to report a bug, post a suggestion, or share your work as contribution!
Plans for the near future
Now we are getting close to the point of this roadmap :)We feel that it is about time to move EurekaLog a bit forward. We are evaluating possibilities for the next direction. Preliminary, we want to add support for:
- Delphi for Mac - MacOS is a closest alternative for Delphi/WIntel platform with a great amount of backward compatibility. EurekaLog is not specific to UI framework, so no VCL -> FMX migration is necessary. We only have to adapt OS-specific calls. Doing MacOS support will allow us to concentrate on removing/adapting Windows-specifics, keeping Delphi specifics at place. Generally, we expect this to be faster and most easy solution.
- Lazarus - while we are not sure about exact amount of interest in exception tracer for Lazarus, we are still consider it as a viable option. Doing Lazarus support will make EurekaLog much more platform-universally ready. Ideally, little changes would be required to port EurekaLog to new platform (once Lazarus support would be implemented). However, doing this initial conversion would come at high cost: not only we have to make cross-platform changes, but we would also have to make Delphi -> Lazarus adaptation. While we know that Lazarus is somewhat Delphi-compatible, but we lack real expertise with it and have some concerns (such as strings support). Luckily, we have to keep our code Delphi 4-compatible, so no complex structures support (like generics) is required.
Aside from primary road, we also have a secondary way of development. EurekaLog Viewer was significantly improved in EurekaLog 7, but still lacks important database qualities: the current build is still based on old file-based approach (even when used with FireBird database). We see a large area for improvements here. Viewer should be upgraded in database support aspect. It also could support "databases" like bug tracker integration. However, since EurekaLog Viewer is auxilary tool and it performs its primary function (view reports) quite well - we consider updating Viewer as lower priority than updating EurekaLog itself. Again, share your thoughts on this!
Distant future
For a very distant future we think about porting EurekaLog to non-Pascal IDEs (such as Visual Studio) by providing a DLL with exposed public interface to control EurekaLog. A mobile world (iOS/Android, perhaps a WinPhone) is also a possibility. We understand groving interest in mobile technologies, but currently lacking "a vision" for mobile error reporting solution.Notes:
1 For example, Delphi 3 support was dropped because Delphi 3 did not have 64-bit integer type (Int64) at all, while Delphi 4+ supports Int64 and (for even later versions) UInt64. While it may looks like you do not need 64-bit integer in 32-bit code, but there are certain places in our code base which have to share the same routines' prototype. (Thanks god, there was support for Unicode since Delphi 3.) Another example: EurekaLog 6 has the ability to delay building call stack for the exception until this exception is handled (by EurekaLog) - normally, exception tracer should build call stack right away (when exception is raised). This feature was possible due to specifics of x86-32 platform. This feature greatly speed up execution of code which raises exceptions and handles them (like try/except block in OnDrawItem handler). However, EurekaLog 7 could not use the same technicue - because it has to support other platforms (Win64), where such feature does not exist. Thus, initial release of EurekaLog 7 (7.0.00) did not have any replacement for this old behaviour. Of course, there were many complains about execution speed of EurekaLog 7 in 32-bit mode. That is why we made improvements in EurekaLog 7 - we introduced "deferred call stacks" option (this option will copy call stack and parse it later) and "speed optimization" option (this option will cache calls to kernel's code).
2 EurekaLog has many unit-tests, as well as integration and system tests. All of these tests are run automaticlly when EurekaLog's installer is build from sources. Installer can not be build if any test fails. However, EurekaLog was not created via TDD approach (Test-Driven Development), and it does not have full code coverage. In particular, we do not have automatic tests for external software (e.g. IDE, SMTP servers, etc.). We also do beta-testing in the form of RC releases. Changes in source code are first made into a current RC version, which is published regulary on our web-site (in customer's control panel). Any customer have ability to download and try this build. Once we get a decent amount of fixes or improvements, and if there was no negative feedback for some time - then we re-release last RC build as new stable version of EurekaLog. Despite all of these measures, there still may be bugs in stable releases. For example, since EurekaLog 7 supports Unicode and Win64, we had to walk through old EurekaLog 6 code looking for places where
Char is mixed with Byte and Pointer is mixed with Integer. While there are some compiler-assisted warnings, but there were little assistance for the most part in our code base (especially for Win64 support). Therefore, we mostly rely on Range Checks, Overflow Checks (both were disabled in EurekaLog 6), and memory profiling. But these checks happen at run-time, not at design-time. And the buggy code may run OK - depending on the actual data. Thus, some bugs may be discovered later. There are other examples when bugs slips through automatic and manual tests. Still, as noted above, we think that latest EurekaLog stable release is quite reliable.
