After a long pause, there are two new Gecode releases. Gecode 6.3.0 is dated 7 July 2026, and Gecode 6.4.0 was released on 15 July 2026.

The two releases play different roles. Version 6.3.0 records the changes that accumulated on its release branch during the seven years since Gecode 6.2.0. Version 6.4.0 is also a new starting point. From now on development is on the main branch, CMake is the intended build system, and releases will be source-only.

If you are starting a new project or upgrading an existing one, 6.4.0 is the version to use. The rest of this post groups the changes by what they mean for users and developers, rather than following the history commit by commit.

Building and using Gecode is more conventional

The most visible change in Gecode 6.4.0 is the build and installation flow. CMake was available before, but it now covers the native build properly and is the intended way to build Gecode. A normal source build looks like this:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel
cmake --build build --target check
cmake --install build --prefix /path/to/install

The install step creates a CMake package. A separate CMake project can therefore consume Gecode without maintaining its own FindGecode.cmake file or manually assembling include paths and libraries:

find_package(Gecode CONFIG REQUIRED)

add_executable(my-model main.cpp)
target_link_libraries(my-model PRIVATE Gecode::gecode)

The aggregate Gecode::gecode target is the simple default. Projects that want to state a narrower dependency can request and link individual components, such as driver, flatzinc, or gist. The package also exports Gecode_VERSION, so downstream version checks no longer need to inspect generated headers.

The new packages carry transitive dependencies and record which optional components were built. That is particularly useful for installations involving MPFR, Qt, or Gist. Qt 6 is now preferred, while Qt 5.15 and later remains supported.

The minimum CMake version is 3.21, and the current build expects a C++17-capable compiler. The Autotools build remains supported in 6.4.0, but is planned for removal in a later release. The maintenance generators have also moved from Perl to Python scripts run through uv, which makes the maintenance environment easier to reproduce. Ordinary CMake builds use the generated files included in the source release and do not need to run those scripts.

MiniZinc and FlatZinc have caught up

Much of Gecode 6.3.0 brings its MiniZinc integration up to date. The accumulated changes include:

• support for the standard sliding_among and regular_set constraints;
• the full cumulatives scheduling constraint, including optional activities for cumulative and disjunctive;
• solver configuration and library files installed in the locations expected by MiniZinc;
• value, domain, and bounds propagation annotations;
• better FlatZinc errors, including MiniZinc constraint names when they are available; and
• the experimental on_restart interface for expressing restart-based meta-search.¹

Several fixes are small individually but important together. Array arguments are correctly unshared for constraints such as inverse, division, modulo, arg_min, arg_max, and tables. Element constraints can preserve index offsets rather than introducing transformed arrays. Zero-duration tasks, empty sets, integer powers, and Boolean tables now follow their intended MiniZinc semantics.

Gecode 6.4.0 adds support for the experimental MiniZinc black-box propagator interface.² A FlatZinc model can connect a custom value or bounds propagator implemented in either a shared library or a persistent subprocess. The propagator returns both its result and the dependencies that determine when it must run again. This is an interesting middle ground: a model can use specialized propagation without first adding a native propagator to the solver itself.

The black-box interface is experimental, so it should be treated as a place to explore rather than a frozen long-term API. Still, it opens up a useful route for testing propagator ideas from MiniZinc.

New propagation choices

Gecode 6.4.0 adds selectable support representations for extensional integer constraints.³ A TupleSet can use dense, sparse, or compressed-dense supports, or let Gecode choose automatically. The selected representation is then used by the corresponding table propagator. FlatZinc tables and examples that materialize larger tuple sets use automatic selection.

The tuple sets for table constraints can have very different shapes. A representation that works well for a small dense table is not necessarily suitable for a large sparse one. Making this choice explicit, while providing an automatic mode, gives both library users and the FlatZinc interpreter a better way to balance memory use and propagation work.

Bin-packing propagation has also been strengthened with lower bounds based on dual-feasible functions.⁴ These bounds can detect infeasible packing states earlier than the previous propagation alone. The advanced propagation level is now the default.

Correctness and stability work

The less visible part of 6.4.0 is also the part I value most in a solver release: a broad round of correctness and stability fixes.

Two integer propagator fixes address serious corner cases. Domain-level global cardinality propagation could lose solutions by counting assigned variables twice and retaining stale conflict information. The sorted constraint could fail to terminate when a matching component had no compatible interval. Both have regression tests.

Floating-point propagation received a similar pass. Interval medians no longer overflow near large bounds, which could otherwise prevent search from making progress.⁵ Multiplication, power, and nth-root propagation now contract intervals directly and avoid several tight-bound and even-root corner cases.

Search and cloning were tested under sanitizers and deterministic fault injection. This uncovered races and lifetime issues in parallel search, undefined behaviour during branch-and-bound recomputation, and incomplete cleanup when allocation fails while cloning a space or constructing MiniModel expressions. Failed cloning is now transactional: the source space is restored and the partial clone is released instead of leaving forwarding links or actor lists in an inconsistent state.⁶

These are unusual execution paths, which is precisely why the new test support is useful. Allocation failures and timing-dependent search races are difficult to reproduce through ordinary examples. Dedicated fault-injection and sanitizer configurations make these failures reproducible enough to catch regressions.

Version 6.3.0 already did preparatory work in the same direction. Platform-specific thread implementations were replaced by standard C++ threads, statistics counters were widened for long-running searches, the test suite gained parallel execution, and a leak in parallel search was fixed.⁷ Version 6.4.0 builds on that foundation with current Windows, macOS, and Linux CI coverage.

Compatibility changes to check

There are three changes worth checking before updating an existing build:

1. Releases are source-only. There are no Gecode-provided Windows installers or macOS disk images for 6.4.0.
2. The old qecode and quacode contrib modules are no longer part of the repository or release archive. Projects that still depend on them must keep an older release or maintain the modules separately.
3. The public GECODE_FLATZINC_VERSION macro has been removed. It described a fixed FlatZinc language revision, while current MiniZinc integration is capability-based. Use GECODE_VERSION for the Gecode release, and the installed MiniZinc solver metadata for FlatZinc capabilities.

Static Windows clients using the older GIST_STATIC_LIBS spelling continue to work, although GECODE_STATIC_LIBS remains the preferred macro.

Getting the release

Gecode 6.4.0 can be downloaded from the Gecode download page or from the GitHub release. The source is also available directly from the release-6.4.0 tag.

For all individual changes, see the 6.4.0 and 6.3.0 changelog. The reference documentation and Modeling and Programming with Gecode have also been rebuilt for the release.

This pair of releases clears a substantial backlog, but the more important change is organizational: there is one active development branch and a build that fits current C++ projects. That gives future Gecode work a much firmer base than another isolated collection of fixes would have done.