Gosl v1.2.14 - Docker Toolchain and Maintenance Mode

Gosl v1.2.14 was published on 28 September 2026, arriving shortly after v1.2.13 to deliver an isolated container build and test toolchain without modifying library source files. The Go code in this release remains completely identical to v1.2.13, preserving all exported API signatures, runtime behaviors, and external Go module dependencies. This release is a stable general release rather than an unstable prerelease, intended for engineers who require predictable Cgo builds without managing native scientific libraries on host systems.

The full release notes and downloads are on the GitHub release page.

Compiling numerical Go software that interfaces with native linear algebra libraries introduces operational complexity. Gosl links via Cgo against complex external libraries, including OpenBLAS, LAPACKE, SuiteSparse, FFTW3, and METIS. Prior workflows required developers and continuous integration workers to install matching shared libraries and headers across heterogeneous host distributions.

Version v1.2.14 resolves this compilation friction by introducing a container build setup defined in docker/Dockerfile. The container environment pins Ubuntu 24.04 and Go 1.27.1 with GOTOOLCHAIN=local to enforce local toolchain boundaries. Inside the image, the build installs the exact library versions required by Gosl Cgo definitions: SuiteSparse 7.6.1, OpenBLAS 0.3.26, LAPACKE 3.12.0, FFTW3 3.3.10, METIS 5.1.0, MUMPS-seq 5.6.2, and gfortran 14.2. The container records this exact inventory directly in /etc/gosl-libs.txt.

A shell wrapper at ./gosl orchestrates the container workflow. The script wraps docker run across standard tasks, supporting subcommands all, build, test, race, vet, fmt, cover, bench, shell, and go. The wrapper executes inside the container under the current host user identity, ensuring that compiled artifacts and cache files written to the host filesystem are never owned by root. Intermediate build states persist in the gitignored .docker-cache/ directory.

The container workflow operates completely offline once built, requiring no network connectivity during compilation or test passes. In verification runs across all nineteen packages, executing ./gosl all printed SUCCESS in 14.2 seconds from a cold cache, dropping to 4.6 seconds once cache files were warm.

Alongside the modern Docker toolchain, release v1.2.14 purges legacy development container assets. The maintainers removed the .devcontainer/ directory and deleted the legacy root Dockerfile. That previous configuration ran on Ubuntu 22.04, requested GO_VERSION=latest without pinning, and configured a vscode user using two vendored Microsoft provisioning scripts.

The update also removes the zscripts/ directory, which previously handled automated building and publishing of the gosl/gosl container image to Docker Hub. While previously pushed tags remain accessible on Docker Hub for legacy workloads, the upstream repository will no longer publish automated builds to that registry. Removing these components eliminates unpinned base dependencies and isolates repository automation from third party editor configurations.

The updated documentation formally documents project lifecycle status. Gosl is stable, mature, and currently in maintenance mode. The library has powered published academic research, but active feature development has officially concluded.

New numerical computing initiatives have transitioned to Russell, the designated successor project. Platform engineers and data teams designing greenfield numerical pipelines or linear algebra workflows are advised to evaluate Russell first. The Gosl maintainers continue to accept reports concerning defects in existing routines, but new functional features will not be merged.

The rewritten README.md introduces explicit licensing documentation for package gm/tri. This package provides spatial triangulation routines by wrapping Triangle, the two dimensional Delaunay triangulator and Voronoi diagram generator authored by Jonathan Richard Shewchuk.

The documentation notes that Shewchuk permits Triangle usage for private, academic, and institutional evaluation without royalty. However, distributing Triangle as part of a commercial system requires direct contractual arrangements with the author. Furthermore, the repository documents that the vendored copy within Gosl includes custom adaptations rather than matching upstream Triangle version 1.6 verbatim, complying with the distribution stipulations established by the original author.

Upgrading to v1.2.14 requires no Go code refactoring. The Go source tree is byte for byte identical to v1.2.13. Projects importing Gosl through go.mod without using the repository Docker scripts do not need to increment their dependency version, as v1.2.13 already contains all current library logic.

For platform operators running integration builds, the new container image can also serve as an isolated compilation environment for downstream applications. Running go get github.com/cpmech/gosl inside the container allows external projects to compile against the verified SuiteSparse, OpenBLAS, and LAPACKE runtime stack without host configuration overhead.