When I started OptaPlanner 18 years ago, I couldn’t dare to imagine that one day it would schedule millions of resources. It is amazing. This would not have been possible without the dedication, innovation, and high-quality work that each core and community contributor has brought to the table.
During the Holidays, I had time to think about the past, present and future of our open source project. What did we do right? What did we do wrong? And how can we improve going forward?
In the Past, OptaPlanner evolved a lot over the years. The big leap forward started in 2020, with ConstraintStreams: constraints written in plain code. Unit test friendly. IDE friendly. Other major improvements, such as Spring/Quarkus integration and our Quickstart repository, made it easy to build REST APIs.
In the Present, we continue the OptaPlanner fork as Timefold and grow our open-source company around it. Timefold’s new score calculation engine is twice as fast, try it yourself. Our solver is now cloud friendly: lightweight (less dependencies) and fast startup times (Java native compilation), with full support for Spring Boot 3 and Quarkus 3. New features include Score Analysis to explain the score of a schedule, and Recommend Fit, to reserve a time slot for a customer on the phone.
In the Yet to Come, we will make Planning Optimization easy to use. By empowering you to develop new planning models with new constraints quickly. By making it simple to scale horizontally and integrate with map providers. We will improve the documentation, release educational videos and provision ready-to-use models. And last but not least, we will welcome Data Scientists and Operations Researchers to our open-source solver. With support for Python alongside Java and Kotlin. The future of Timefold is bright.
It’s wonderful to see how our community is growing. Join us. Together, let’s make 2024 the year of Planning Optimization!
Geoffrey De Smet, CTO
Timefold Solver Community Edition 1.6.0. full release notes
Pinning of list variables
With a new
@PlanningPinToIndex annotation, you can tell the solver that a certain portion of the list variable is pinned and shouldn’t be moved.
For example, for a list of customers that a vehicle will visit, this allows you to model situations where certain visits have either already happened, or where the vehicle is already too far into the trip that it would not be practical for it to turn back.
Previously, pinning was only available for the chained variable. With this, we are ramping up our efforts to bring list variable, which is easier to both understand and implement, on par with the chain variable in terms of features. Stay tuned for more on this front!
Solver termination can now be overridden without creating a new instance of Solver or SolverManager, look for the SolverConfigOverride class.
The usual assortment of bugfixes and performance improvements.
Improvements all over the documentation and quickstarts.
Here you can find all previous releases of Timefold Solver