Writing good software isn't always easy; writing good and versatile open-source software that scales with time, with complexity, with amount and diversity of code authors, while increasing its development speed and keeping a huge ecosystem of extenders healthy for an extremely low to null maintenance cost on adopter's shoulders thanks to backward compatibility is even more challenging.
This is the challenge the Eclipse Platform has successfully faced for soon to be 2 decades, and has made it almost trivial to deal with in the last months.
Relying on OSGi and related good practices about compatibility have made it possible, and the PDE API Tools have made it easy to let APIs evolve while preventing some typical API and version compatibility issues, by either showing warnings/errors in the IDE or by some (complex Ant) automation to generate a report - that a human still have to read to detect whether it's good or bad-. However, despite existence of those very good tools and probably because of the acceleration of Platform development and the growth of its community of contributors, the frequency of such issues was getting higher. We identified that the current API Tools are still often hard to configure for some contributors/reviewers and that they were often disabled or skipped, leading to some merged commits breaking API or version rules and requiring interruptions and further resolutions.
To overcome this trouble, the Platform has recently enabled an easy way to automate API Compatibility and Version enforced at no cost for the developer, during the contribution processed in a step that cannot be easily avoided: the patch submission and code review step. Thanks to some improvements in PDE, one can now easily enable in their build this verification phase and get a CI bot voting -1 on patches that don't fit in the API Compatibility and Versioning criteria, preventing incompatibilities from being merged and giving hints to the contributors on what needs to be fixed. This was deployed for Eclipse Platform contribution process (Gerrit+Jenkins) in July.
After reminding the context about why API and version matter, we'll give a brief and basic (but incomplete) explanation of how existing PDE API Tools work in general to check API Compatibility and OSGI Semantic Versioning in the IDE; then we'll
detail how you can enable them in your build and focusing on a Maven/Tycho case, using some examples like Eclipse Platform. Afterwards, we'll quickly discuss about how it would be possible to use it in typical other build-systems and finally we'll try to show by numbers how this automation reduced the amount of merged bugs and related noise typically produced during a Platform release cycle (3 months).