Heavy Refactoring
To make Operaton a truly open and community-driven project, we’ve been hard at work:
• Removing trademarks to clear up licensing concerns.
• Refactoring the codebase to ensure we meet open standards.
This wasn’t just a quick change. Refactoring can introduce risks and errors, and we’re being extra thorough to ensure no breaking changes—especially in the Java API—before the first final release.
Modernizing for the Future
We’ve decided to drop support for outdated Java and Spring versions. Why?
• Legacy tech slows innovation.
• Focusing on supported versions gives us a future-proof foundation.
By embracing modern technologies, we’re preparing Operaton to meet the needs of the community today and tomorrow.
Testing Transparency
Integration tests are critical for delivering stability, but we hit a challenge:
• Some tests relied on non-open Jenkins pipelines and private Docker images.
That doesn’t align with our commitment to openness. So, we’re moving:
All integration tests to public infrastructure.
This will allow everyone—not just us—to run, verify, and improve the tests, fostering transparency and collaboration.
Stability, Thanks to You
Early adopters from the community have played a huge role in helping us identify issues and ensure stability. But we’re not stopping there. “Almost stable” isn’t good enough. We’re committed to rigorous testing to make sure the first final release is rock-solid.
What’s Next?
Here’s what we’re working on:
• Moving all integration tests to public infrastructure.
• Providing easy-to-use Docker images for testing and integration.
Once these steps are complete, we’ll share details about the first stable release—tested, verified, and fully open to the community.