After releasing OpenFastTrace 2.1.0 it was high time to release the corresponding Gradle plugin in version 0.5.0. This is a drop-in update, just update the version number and benefit from the features and bugfixes of OFT 2.1.0.

During the release process we also fixed the sonar analysis and some sonar warnings.

We also used the opportunity to document (and test) two features that where already implemented but not described:

• Import requirements from a maven repository
  This is useful for sharing requirements with other sub-projects.
• Publish requirements to a maven repository
  This is useful for tracing against requirements from a higher-level architecture document.

After two bugfix releases a new feature release. On November 19th Christoph create the Release for OpenFastTrace 2.1.0.

Feature-wise we are happy to announce an improved HTML report.

Sonar checks are now up and running again and the last JavaDoc errors have been rooted out.

We also fixed the deep coverage detection which was pointing upwards instead of downwards in the tracing chain. As a consequence we had to rework link loop detection, which acts a lot smarter now than before.

In a recent blog post I wrote about the migration from JUnit4 to JUnit5 as unit testing framework.

Even though the version number increase from 2.0.1 to 2.0.2 might not look like much, it is in fact a major milestone for OpenFastTrace, since from here on writing tests will be faster and more efficient.

Can you accumulate technical dept, even if you regularly clean up your sources meticulously? A short while ago I would have said that this is possible but unlikely. That was before I started taking on the migration of all of OpenFastTrace‘s unit tests from JUnit4 to JUnit5.

This release is a big step forward. One new feature, a few small fixes and a lot of code improvements that gives us a much cleaner and more uniform API, better test coverage and lower overall complexity.

But a new API also means we had to break backward compatibility to achieve something that the existing API would not allow since it had a separation of report and export mode: you can now reuse an import that already ran to create both reports and exports from it without redoing the import. This is a considerable speed-up (and we call the project OpenFastTrace for a reason). Runtime efficiency was and will always be one of our main design principles.