We're happy to announce the sixth alpha release of Dune!

we're happy to announce the fifth alpha release of Dune!

We're happy to announce the fourth alpha release of Dune!

We're happy to announce the third alpha release of Dune!

We're happy to announce the second alpha release of Dune!

We're happy to announce the first alpha release of Dune!

Hi everyone,

We are happy to announce the first release candidate of opam 2.5.0, which boasts a grand total of zero (0) changes compared to 2.5.0~beta1!

Try the new opam 2.5.0 release candidate:

The upgrade instructions are unchanged:

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.5.0~rc1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.5.0~rc1"

Please report any issues to the bug-tracker.

Happy hacking, <> <> The opam team <> <> :camel:

Feedback on this post is welcomed on Discuss!

We are happy to announce the first beta release of opam 2.5.0. You can view the full list of changes in the release note.

This version is a beta, we invite users to test it to spot previously unnoticed bugs as we head towards the stable release.

Try it!

The upgrade instructions are unchanged:

1. Either from binaries: run

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.5.0~beta1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.5.0~beta1"

or download manually from the Github "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Changes

• Allow the macOS sandbox to write in the /var/folders/ and /var/db/mds/ directories as it is required by some macOS core tools (#4389, #6460)
• Stop opam switch create --dry-run from creating any directory. Thanks to @hannesm for this contribution. (#5918)
• Stop cleaning the build directory when installing packages with --dry-run. Thanks to @hannesm for this contribution. (#6540)

Regression fixes from 2.5.0~alpha1

• Fixed a bug occurring on version-equivalent package rename (i.e. pkg.00 -> pkg.0) leading to the package being completely removed (#6754)

Build changes

• opam no longer depends on cmdliner. This change allows cmdliner 2.0.0 to be co-installable with opam-installer and the opam-client library (#6425)
• Allow building opam using the upcoming OCaml 5.5 (trunk) when using dune's dev profile (#6670)
• Clean variables before calling make on different projects (e.g. downloaded-if-missing OCaml compiler) to avoid clashes with other variables set by these projects (#6769)

API changes are also denoted in the release note linked above. This release also includes a couple of improvement and extensions to our testsuite.

Please report any issues to the bug-tracker.

Happy hacking!

The opam repository serves as the central package registry for the OCaml ecosystem, hosting over 4,500 packages and processing nearly 200 new packages and releases each month. Understanding how this critical infrastructure works is essential for any OCaml developer looking to contribute packages or understand the ecosystem's inner workings.

Architecture and Infrastructure

The opam repository operates as a curated Git repository containing package metadata rather than the packages themselves. Each package is described by an opam file that specifies dependencies, build instructions, and other metadata. The package also includes a URL pointing to the source of the actual package. The actual source code remains in the original repositories maintained by package authors.

For example, the yojson.3.0.0 package provides a simple illustration of the package format. For more details, see the opam package format documentation.

The CI Pipeline

At the heart of the repository's reliability is an extensive continuous integration (CI) system built around OCurrent, which powers the opam-repo-ci service. When you submit a pull request to add or update a package, this system:

• Validates package metadata using an extensive set of linting rules
• Tests compilation across multiple OCaml compiler versions (currently supporting back to OCaml 4.08)
• Verifies installation on various platforms including Linux distributions, macOS, FreeBSD, Windows, and multiple CPU architectures (x86_64, ARM64, ARM32, PowerPC, s390x, RISC-V)
• Runs package tests to ensure functionality
• Checks reverse dependencies to ensure your changes don't break existing packages that depend on your package

This comprehensive testing matrix helps maintain the repository's high quality standards. Windows support was added in 2024, marking a significant expansion of the platform coverage.

Supporting Infrastructure

The opam repository integrates with several other OCaml infrastructure services:

• Docker Base Images: The docker-base-images service provides consistent testing environments, building official images for various Linux distributions, OCaml versions, and architectures
• Documentation CI: The docs.ci.ocaml.org service automatically builds and publishes package documentation to the OCaml.org website's package area
• Health Check Services: Multiple services continuously monitor package installability across different platforms and compiler versions:
  • check.ci.ocaml.org: Tests all packages regularly
  • dune.check.ci.dev: Tests packages with the Dune build system - related to the recent addition of the Dune Package Management feature
  • windows.check.ci.dev: Windows-specific testing
  • freebsd.check.ci.dev: FreeBSD compatibility
  • oxcaml.check.ci.dev: Tests with OxCaml compiler variant

Infrastructure Funding

As of 2025, the OCaml.org infrastructure is primarily funded and supported by the Cambridge Computer Lab and Tarides. Additional cloud hosting costs are covered by community contributions. For architecture-specific testing, Oregon State University Open Source Lab provides essential PowerPC infrastructure support, IBM LinuxONE at Marist University provides S390 machines for the CI pipelines, and Jane Street has generously donated x86 machines to Cambridge University. This combination of institutional support, corporate sponsorship, and community backing enables the comprehensive multi-platform testing that ensures package quality across the entire OCaml ecosystem.

Governance and Curation Policies

The opam package repository is a commons rather than a publishing platform: it is manually curated, so not all packages submitted for publication are accepted; it is maintained communally, so anyone can suggest changes to any package.

Core Principles

The repository maintains quality through several key policies, documented in the repository policies. The policies are derived from some core principles, including:

Package Utility: Packages must provide substantial utility to the OCaml community. Single-function modules or packages with minimal functionality are generally rejected to preserve namespace and repository efficiency.

Naming and Security: Package names are reviewed to prevent confusion with existing packages and potential security risks. Name squatting and packages with deceptively similar names to established libraries are not permitted.

Dependency Constraints: The repository discourages overly strict version constraints (using = or <=) as they make package combination difficult and worsen the user experience. Instead, packages should use reasonable upper bounds and allow opam's solver to find compatible combinations.

Maintenance Requirements: Packages must be actively maintained for modern OCaml versions. There is a compiler cutoff threshold, which will be increased as newer releases become available. Packages that don't support recent compiler versions may be archived.

Maintenance Intent Declarations

One distinctive feature of the opam repository is the ability for package maintainers to explicitly declare their maintenance intentions using the x-maintenance-intent field in package metadata. This allows maintainers to express their commitment level upfront—you don't need to be stuck maintaining something forever. This is fairly unusual in package ecosystems and provides clarity for both maintainers and users.

When maintainers indicate they're no longer supporting certain versions or stepping back entirely, the community is notified. If no new maintainer volunteers, packages that no longer meet the compiler cutoff threshold or are marked as unmaintained get moved to the opam-repository-archive rather than being removed entirely. This archiving process helps manage repository growth while preserving historical packages.

The Human Element

Review Process

Every package submission undergoes human review in addition to automated testing. Maintainers check for compliance with repository policies, verify licensing information, assess package utility, and ensure proper dependency declarations. This human oversight is crucial for maintaining the repository's curation standards.

Maintainer Team and Acknowledgments

The repository is maintained by a dedicated team of volunteers who review every package submission. The current active maintainers are listed in the governance documentation.

The opam-repository has benefited from the contributions of many dedicated individuals over the years. Since its inception, Anil Madhavapeddy, Thomas Gazagnaire, and Jeremy Yallop established the foundations of the repository and its processes. Kate Deplaix (kit-ty-kate) served as the primary maintainer from 2017 to 2024, during which time she established many of the current processes, comprehensive documentation, and quality standards. She now contributes to the opam tool itself.

Today's active maintenance team includes Marcello Seri, Shon Feder, Raphaël Proust, Hannes Mehnert, and Jan Midtgaard, who review submissions and ensure the repository's continued quality. The CI infrastructure is maintained by Mark Elvers, whose work keeps the testing systems running smoothly — a laborious but essential task.

Beyond package review, Hannes Mehnert has been working on initiatives like Conex to improve package security since 2015.

We extend our heartfelt gratitude to all these maintainers, contributors, and everyone else who has helped make the opam-repository a reliable foundation for the OCaml ecosystem. Their tireless volunteer work reviewing submissions, upholding quality standards, and providing guidance to contributors is essential to the health and continued growth of our community.

Community Involvement

The maintainer team actively seeks new volunteers to help manage the growing submission volume. The role offers excellent opportunities to:

• Connect with and support contributors from across the OCaml ecosystem
• Learn advanced packaging techniques and build system intricacies
• Contribute to ecosystem sustainability and health
• Gain experience with large-scale open source project management

For information about the onboarding process, see the Onboarding documentation. If you're interested in contributing to this essential piece of OCaml infrastructure, check out the call for volunteers or reach out to the current maintainer team.

Publishing Workflow

For package authors, the typical publishing workflow involves:

1. Creating a package source archive (commonly done by pushing a git tag to your online forge of choice: GitHub, GitLab, Codeberg, or other)
2. Opening a pull request to opam-repository (often automated with tools like dune-release or opam-publish)
3. Monitoring the pull request's CI results and addressing any build failures or policy violations
4. Responding to maintainer feedback during the review process
5. Package acceptance and automatic propagation to opam users worldwide

The process is streamlined by extensive documentation including the CONTRIBUTING.md guide and the comprehensive wiki that covers everything from basic submission guidelines to detailed policy explanations.

Looking Forward

The opam repository continues to evolve as the OCaml ecosystem grows. Recent initiatives include the introduction of an archiving policy, improving maintainer documentation, and scaling the review process to handle increasing submission volumes.

A Thriving Ecosystem

The opam repository's design as a shared metadata format has enabled a diverse ecosystem of tools and repositories. Multiple package management clients can consume opam metadata, including the traditional opam client, Dune's package management, esy, and even Nix. This flexibility demonstrates the health and maturity of the OCaml package ecosystem.

Beyond the main repository, there's a rich ecosystem of specialized package repositories that complement it. These include cross-compilation overlays (notably for Windows and iOS), organization-specific repositories (such as Jane Street's packages and OxCaml), and domain-specific collections like the Rocq proof assistant packages. By design, these repositories can be stacked and composed together, allowing users to mix and match packages from different sources while maintaining dependency resolution.

For developers interested in contributing to this critical infrastructure, whether as package authors or potential maintainers, the repository represents one of the most impactful ways to support the broader OCaml community. The combination of technical infrastructure, human oversight, and community governance makes the opam repository a model for how modern package ecosystems can balance growth with quality.

Feedback on this post is welcomed on Discuss!

We are happy to announce the first alpha release of opam 2.5.0. You can view the full list of changes in the release note.

This version is an alpha, we invite users to test it to spot previously unnoticed bugs as we head towards the stable release.

Try it!

The upgrade instructions are unchanged:

1. Either from binaries: run

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.5.0~alpha1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.5.0~alpha1"

or download manually from the Github "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Major changes: speedup opam update up to 70%

Thanks to @arozovyk, opam update now loads opam file incrementally, only parsing the files that have changed since the last time you called opam update. Before that, opam files in opam repositories were all loaded from the file system after an update if there was any change. The performance improvement of this change thus depends on how often you call opam update and what type of repository and OS you are using. (#5824)

Major changes: improved shell integration

A number of users have been hitting issues with opam's shell integration where parts of a previous environment was kept in the current environment, causing a number of issues. These can be triggered by, for example, nuking your opam root directory (by default ~/.opam or %LocalAppData%\opam). For this particular case we are still working on a fix, but many other users have reported similar issues without nuking their root directory and in that case we believe to have fixed the majority of issues. (dbuenzli/topkg#142, #4649, #5761)

On top of that, for bash users, we've also changed the default file to which opam init writes the opam shell integration to be .bashrc instead of the previous .profile or .bash_profile. Doing it this way prevents some issues with existing .profile files that source the .bashrc file and causing an infinity loop when opam asks users to make sure to source their .bashrc file into their .profile file. (#5819, #4201, #3990)

We invite users to test this change for the editor integration, to spot any bug early.

Change to the install script

The opam install script now installs an appropriate apparmor profile on systems configured with apparmor. This change is not strictly speaking related to this release as it is deployed for every versions. (#5968)

We invite apparmor users (enabled by default on Ubuntu), to test this feature and let us know if some adjustments are needed.

Other noteworthy changes

• Archives without checksums are now fetched only once per call of opam install if their url match (#5638)

• extra-files whose name is invalid now make opam fail early instead of ignoring the error (#6679)

• The specification of the pkg:opamfile variable was refined and its computation was updated accordingly (#5346)

• The global option default-invariant is now modifiable. This is used as default value when creating a local switch (#6730)

• opam now makes sure that git submodules are up-to-date when checking if a source git repository is up-to-date. This caused issues on subsequent package updates when git submodules originally failed to download or when the submodules got updated in some cases (#6132)

• Fix opam install pkg --depext-only exiting with code 0 instead of 20 (not found) (#6488)

• Fix the parsing of OPAMFETCH (support quotes / proper POSIX shell syntax) (#5490)

• Fix opam remove --force that was launching commands in current directory (#6570)

• Fix opam lock's error message on pinned packages with no git remote by handling exit code 2 from git remote get-url (#6422)

• getconf was removed from the list of required runtime tools, which allows opam init to work out-of-the-box on Haiku (#6632)

• ./configure --enable-static is now supported on OpenBSD. This mode is used in the prebuilt release binaries (#6705, thanks to @flumf)

Half a dozen UI improvements, such as improved error messages, handling of uncaught exceptions, displaying the invalid character in erroneous package names (contributed by @lefessan), etc.

Various performance and other improvements were made and bugs were fixed. API changes are also denoted in the release note linked above. This release also includes a handful of improvement the documentation and more than two dozen improvement and extensions to our testsuite.

Please report any issues to the bug-tracker.

Happy hacking!

Gospel, the behavioral specification language for OCaml, is at an interesting inflection point. After years of development and research, some tools in the ecosystem—particularly Ortac/QCheck-STM—are ready for early adopters to try on real codebases. At the same time, Gospel itself is preparing a major release with breaking changes as the language design continues to evolve.

Making Formal Methods Accessible

Traditionally, formal verification delivers strong correctness guarantees but requires significant expertise and resources. Gospel's vision is different: one specification language that will eventually support multiple verification strategies, from lightweight runtime testing to full mathematical proofs. While the testing tools are available today, the proof tools are still under development.

This approach follows a successful pattern established in other language ecosystems. ACSL (ANSI/ISO C Specification Language) provides a behavioral specification language for C programs that supports multiple verification tools including Frama-C, while JML (Java Modeling Language) offers a unified specification language for Java that can be used for runtime assertion checking, static analysis, and theorem proving. Similarly, Eiffel pioneered the concept of design by contract with specifications embedded directly in the programming language. Gospel brings this proven strategy to OCaml.

Gospel provides a non-invasive syntax for annotating OCaml interfaces with formal contracts in special comments beginning with @, describing type invariants, mutability, pre-conditions, post-conditions, and exceptions. The specifications use logical models to represent abstract types—for example, modeling a queue as a mathematical sequence to specify how operations transform its contents.

Status of Gospel and its Toolkit

Gospel language (experimental, major changes coming) is preparing a release with significant breaking changes. Early adopters should expect the language to evolve and should not expect bug fixes in the current version.

Gospel's tool-agnostic design powers an ecosystem of verification tools at different maturity levels:

Ortac provides dynamic verification through runtime assertion checking and automated test generation:

• Ortac/QCheck-STM (released, battle-tested) generates black-box state-machine tests and has found real bugs including missing bounds checks in varray, integer overflows causing segfaults in bitv, inconsistent behavior with zero-length vectors in bitv, and unexpected behavior in the standard library's Hashtbl.create. Supports higher-order functions like map.
• Ortac/Wrapper (released, early stage) instruments functions with runtime assertions but hasn't been extensively tested in production yet.
• Ortac/Monolith (experimental) provides fuzzing integration with Monolith.

Cameleer (working toward first release) translates Gospel into Why3 for deductive verification using automated theorem provers.

Peter (ongoing research) explores separation logic verification through CFML integration with Coq for complex heap manipulation proofs.

Open Source Infrastructure Strategy

Gospel development is funded by ANR grant ANR-22-CE48-0013, executed through collaboration between Nomadic Labs, Tarides, Inria, and LMF (Laboratoire Méthodes Formelles) at Université Paris-Saclay. The project demonstrates how open source can transform formal verification economics: rather than each organization independently funding expensive verification efforts, shared open tooling and verified libraries benefit the entire ecosystem.

Current State and Integration

Ortac/QCheck-STM is released and has proven effective on real codebases, with test runs completing in hundreds of milliseconds. Gospel itself is experimental with major language changes planned, so early adopters should expect breaking changes.

The OCaml Platform roadmap through 2026 includes formal verification as a workflow goal. Currently, using Ortac requires writing Dune rules manually. Integration with Dune as a first-class feature requires further discussion and development.

Try Ortac/QCheck-STM Today

Install via opam:

opam install ortac-qcheck-stm

This installs the ortac command-line tool and everything needed to generate QCheck-STM tests from Gospel specifications. See the Ortac tutorial for a complete walkthrough, or check the QCheck-STM plugin README for details.

The project welcomes early adopters who want to:

• Try Ortac/QCheck-STM on production codebases and report bugs found
• Provide feedback on Gospel's evolving specification language
• Share use cases that could benefit from formal verification

The VOCaL (Verified OCaml Library) project demonstrates Gospel's potential with formally verified data structures.

What to Expect

The verification infrastructure is already useful for testing — bugs are being found, specifications provide value as documentation. Work on establishing the path from testing to formal proofs is ongoing, but the proof tools aren't ready for general use yet.

Learn More

The ecosystem is open source and actively developed. Explore the Gospel GitHub organization, or review research papers:

• GOSPEL — Providing OCaml with a Formal Specification Language (FM 2019)
• Static and Dynamic Verification of OCaml Programs: The Gospel Ecosystem (ISoLA 2024)
• Dynamic Verification of OCaml Software with Gospel and Ortac/QCheck-STM (TACAS 2025, Best Tool Paper award from ETAPS)

For teams interested in specification-driven testing, Ortac/QCheck-STM is ready to try. For those interested in formal proofs or stable Gospel language features, watch the project but expect it will be some time before these are production-ready.

Contact: @n-osborne | Get started: Ortac Tutorial | Documentation: Gospel docs

Discuss this post on discuss!

We're excited to announce ocaml.nvim, a new Neovim plugin actively being developed by Tarides that brings advanced OCaml development features to Neovim users. Think of it as the Neovim sibling of ocaml-eglot, which we released earlier this year for Emacs users.

What is ocaml.nvim?

Modern code editors communicate with programming languages through the Language Server Protocol (LSP), which provides essential features like syntax checking, code navigation, and auto-completion. However, OCaml's language server exposes powerful custom commands beyond what generic LSP clients can access.

ocaml.nvim works alongside generic Neovim LSP plugins like nvim-lspconfig, providing direct access to advanced ocamllsp features without requiring complex editor-side logic. The plugin gives you access to all the advanced Merlin commands not supported by generic LSP clients.

Key Features

Typed Holes Navigation - Navigate between typed holes (_) and interactively substitute them with the Construct command.

Semantic Navigation - Move through your code semantically: jump between expressions, parent let bindings, modules, functions, and match expressions.

Phrase Navigation - Move between OCaml phrases (top-level definitions) in your buffer.

Many more features are in development, including alternating between .ml and .mli files, type enclosing, and pattern matching generation.

Getting Started

Installation is straightforward with lazy.nvim:

require("lazy").setup({
  { "tarides/ocaml.nvim",
    config = function()
      require("ocaml").setup()
    end
  }
})

The plugin complements your existing LSP setup—you'll continue to use Neovim's built-in LSP for standard features while ocaml.nvim adds OCaml-specific capabilities.

Project Status

The ocaml.nvim repository is now public on GitHub, with comprehensive documentation, a feature table, and screencast demonstrations. We're working towards a stable 1.0 release and welcome feedback from the community.

Try out ocaml.nvim and let us know what you think! For questions or feedback, reach out to Charlène Gros at charlene@tarides.com, join the discussion on the OCaml Discuss forum, or post an issue on the ocaml.nvim GitHub repository.

The Merlin team is excited to share that you can now try out an experimental branch of Merlin that leverages OCaml 5's domains and effects! This is Merlin-domains, and we'd love for you to test it and share your feedback.

What is Merlin-domains?

Merlin-domains is an experimental branch that uses domains and effects to implement two optimisations to improve performance in large buffers: partial typing and cancellation.

As a reminder, Merlin is the editor service that powers OCaml's IDE features—if you're using the OCaml Platform extension with VS Code or ocaml-eglot with Emacs, you're already using Merlin under the hood through OCaml LSP Server.

Why This Matters

While Merlin has had relatively few performance complaints over the years, in some contexts like very large files, the parsing-typing-analysis mechanism could sometimes cause slowdowns. The experimental branch addresses this in a clever way.

When you run an analysis command on a very large file, the type-checker will progress up to the location that makes the analysis possible, run the analysis phase, return the result, and then continue typing the file. This separation is made possible through control flow management enabled by effects, with two domains interacting with each other.

The result? Analysis phases become much more efficient! This is a great example of migrating a regular OCaml application to take advantage of multicore.

Learn More at Lambda World

Want to understand the technical details? Sonja Heinze and Carine Morel will present their talk "When magic meets multicore - OCaml and its elegant era of parallelism" at Lambda World, where they'll dive into how this experimental branch works internally.

How to Test It

Currently, the branch is in its incubation phase. To test it, pin the branch in the switches where you want to experiment:

opam pin add https://github.com/ocaml/merlin#merlin-domains

Although this experimental branch passes the test suite, your feedback is very important to help collect potential bugs we may have missed. The team has added a Bug/Merlin-domains label to organize tickets related to this branch.

What's Next

The goal is for this branch to eventually become the main branch, so that all users can benefit from these improvements. The rest of the ecosystem depending on Merlin, including OCaml LSP Server, will be adapted to take full advantage of these new features.

We need you! Try out merlin-domains with your real-world OCaml projects and share your experience on the Discuss thread. Your testing and feedback will help shape the future of Merlin!

The release of OCaml 5.4.0 is imminent.

As a final step, we are publishing a release candidate to check that everything is in order before the release in the upcoming week.

If you find any bugs, please report them on the OCaml's issue tracker.

Compared to the second beta, this release candidate only contains a fix in the TSAN mode, and one metadata fix in the changelog itself. The full change log for OCaml 5.4.0 is available on GitHub.

Happy hacking,
Florian Angeletti for the OCaml team.

Installation instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.4.0~rc1

The source code for the release candidate is also directly available on:

• GitHub: https://github.com/ocaml/ocaml/archive/5.4.0-rc1.tar.gz
• OCaml archives at Inria: https://caml.inria.fr/pub/distrib/ocaml-5.4/ocaml-5.4.0~rc1.tar.gz

Fine-tuned compiler configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.4.0~rc1+options <option_list>

where <option_list> is a space-separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.4.0~rc1+flambda+nffa ocaml-variants.5.4.0~rc1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

After an extended summer break, the release of OCaml 5.4.0 is getting close.

Since there have been a handful of meaningful bug fixes this summer, we are releasing a second beta version of OCaml 5.4.0 to help you update your software and libraries ahead of the release (see below for the installation instructions). More information about the whole release process is now available in the compiler repository.

Compared to the first beta release, this beta release contains four notable bug fixes:

• one type system bugfix for variance annotation on private types
• one memory concurrency safety fix for weak pointers
• two Windows fixes

Those fixes are complemented by:

• one runtime performance fix
• three tools and compiler-libs related fixes
• one error message fix.

The full list of fixes for this second beta is available below.

Overall, this beta release is already quite stable. If the tests for this beta release go well, we are expecting to have a first release candidate in the week of the 22 September, and the full release in the beginning of October.

If you find any bugs, please report them on OCaml's issue tracker.

The last progresses on stabilising the ecosystem are still tracked on the opam readiness for 5.4.0 meta-issue.

If you are interested in full list of features and bug fixes of the new OCaml version, the updated change log for OCaml 5.4.0 is available on GitHub.

Happy hacking,
Florian Angeletti for the OCaml team

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.4.0~beta2

The source code for the beta is also available at these addresses:

• GitHub
• OCaml archives at Inria

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.4.0~beta2+options <option_list>

where option_list is a space separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.4.0~beta2+flambda+nffa ocaml-variants.5.4.0~beta2+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

Changes since the first beta

Type system fix

• #14200, #14202: bad variance check with private aliases
  (Jacques Garrigue, report and review by Stephen Dolan)

Windows fixes

• #13504, #13625, #14223: Add Thread.set_current_thread_name.
  (Romain Beauxis, review by Gabriel Scherer and Antonin Décimo)

• #13541, #13777: Using C++11 thread_local causes name-mangling issues when linking with flexlink on Cygwin.
  (Antonin Décimo and David Allsopp, report by Kate Deplaix)

Runtime fixes

• #14061, #14209: fix a memory-ordering bug in Weak.set that could result in uninitialized memory seen by Weak.get on another domain.
  (Damien Doligez, review by Gabriel Scherer)

• #14169: runtime, fix cache miss within the stack fragments cache
  (Florian Angeletti, review by Gabriel Scherer)

Tooling fixes

• #13302, #14236: Store locations of longidents components
  (Ulysse Gérard and Jules Aguillon, review by Jules Aguillon and Florian Angeletti)

• #12642, #13536, #14184, #14192: in the toplevel, print shorter paths for constructors and labels when only some modules along their path are open.
  (Gabriel Scherer, review by Florian Angeletti)

• #14196, #14197: ocamlprof: do not instrument unreachable clauses
  (Gabriel Scherer, review by Nicolás Ojeda Bär, report by Ali Caglayan)

Error messages

• #14214, #14221: fix a confused error message for module inclusions, functor error messages were missing some type equalities potentially leading to nonsensical "type t is not compatible with type t" submessage
  (Florian Angeletti, report by Basile Clément, review by Gabriel Scherer)

Dune 3.20.0_alpha4 was released, with no user-facing changes.

Dune 3.20.0_alpha3 was released, with no user-facing changes.

Dune 3.20.0_alpha2 was released, with no user-facing changes.

We released Dune 3.20.0_alpha1 as a minor alpha release that adds one new feature and fixes a documentation reference:

• New Feature: Added timeout support for cram tests - you can now specify (timeout <float>) in cram stanzas to automatically terminate tests that run too long
• Documentation Fix: Corrected a reference in the RPC warning changelog entry

This unstable alpha release builds on alpha0 with minimal changes focused on improving test reliability and documentation accuracy.

Dune 3.20.0~alpha0 is now available with several user-facing improvements and fixes.

Summary of Changes

Testing improvements: Individual tests can now be run using named aliases (@runtest-<name>), dune runtest accepts absolute paths and can target specific build contexts, and cram tests have better process cleanup.

New command-line features: dune exec works concurrently with watch mode, dune promote runs while watch mode is active, dune describe location shows executable paths, and --alias/--alias-rec flags provide alternatives to @/@@ syntax.

New variables: Added %{os}, %{os_version}, %{os_distribution}, and %{os_family} variables matching opam equivalents.

Fixes: dune subst properly handles version fields in opam files and works when no version control is detected.

Under the hood: Switched from MD5 to BLAKE3 for better performance, improved s-expression formatting, and added smart handling of transitive dependencies based on compiler capabilities.

Installation

opam install dune.3.20.0~alpha0

This is an alpha release for testing. Report issues on GitHub.

Two months after the release of the first alpha for OCaml 5.4.0, the release of OCaml 5.4.0 is drawing near.

The internal API of the compiler libraries has been frozen, and most core developer tools support (or will support soon) the new version of the compiler. We have thus released a first beta version of OCaml 5.4.0 to help you update your softwares and libraries ahead of the release (see below for the installation instructions).

Compared to the first alpha release, this beta release brings two notable changes. First, this beta partially reverts the changes of symbol names in executable (in order to keep current version of perf working with OCaml executable). Second, this beta fixes a significant performance issue on Apple Silicon macOS.

Beyond these two changes, this first beta release contains a dozen of small bug fixes (from the runtime to the error messages) which is usual for the stage of the release. We are expecting the release candidate to follow this beta release soon in the beginning of August.

The progresses on stabilising the ecosystem are tracked on the opam readiness for 5.4.0 meta-issue.

The full release is expected in the middle of August, see the new prospective calendar for more information.

If you find any bugs, please report them on OCaml's issue tracker.

If you are interested in full list of features and bug fixes of the new OCaml version, the updated change log for OCaml 5.4.0 is available on GitHub.

Happy hacking, Florian Angeletti for the OCaml team

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.4.0~beta1

The source code for the beta is also available at these addresses:

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.4.0~beta1+options <option_list>

where option_list is a space separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.4.0~beta1+flambda+nffa ocaml-variants.5.4.0~beta1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

This is the first release candidate of opam 2.4.0.

Binaries and full archive are signed by the opam dev team (fingerprint 92C5 26AE 50DF 3947 0EB2 911B ED4C F1CA 67CB AA92).

Please see our blog post for a highlight on the major changes and upgrade instructions.

This is the first beta release of opam 2.4.0.

Binaries and full archive are signed by the opam dev team (fingerprint 92C5 26AE 50DF 3947 0EB2 911B ED4C F1CA 67CB AA92).

Please see our blog post for a highlight on the major changes and upgrade instructions.

Discuss this post on discuss!

Dune lock directories record the names of any system packages needed to build projects or their dependencies. Currently this information is not portable because Dune only stores the names of system packages within the package repository on the machine where the lock directory is generated. We've recently changed how Dune stores the names of system packages in the Dune Developer Preview so that the names of packages in all known package repositories are stored. This allows a lock directory generated on one machine to be used on a different machine.

Background on depexts in Opam

A system package, or external dependency, or depext as I'll refer to them from now on, is a piece of software which can't be installed by Opam directly, but which must be installed in order for some Opam package to be built or for code in an Opam package to be executed at runtime. These packages must be installed by the system package manager, or by some other non-Opam means such as manually building and installing the package from source. Common types of depext are build tools such as the pkg-config command, often run to determine linker flags while building a package, or shared libraries such as libgtk, which an OCaml project might link against to create GUIs.

Opam usually installs depexts automatically. Opam knows how to invoke many different system package managers (such as apt or pacman), so when installing a package with depexts Opam can run the commands appropriate to the current system to install the required packages using the system's package manager. For this to work, Opam needs to know the name of the package within the package repository appropriate to the current system, and these names can vary from system to system. For example the pkg-config command is in a package named simply pkg-config in the apt package manager on Ubuntu/Debian systems, whereas in the third-party homebrew package manager on MacOS it's in a package named pkgconf. In order to determine the right package name for the current system, the package metadata for Opam packages with depexts contains a list of all the different known package names along with the conditions under which that name is correct. Here is that list for the conf-pkg-config Opam package:

depexts: [
  ["pkg-config"] {os-family = "debian" | os-family = "ubuntu"}
  ["pkgconf"] {os-distribution = "arch"}
  ["pkgconf-pkg-config"] {os-family = "fedora"}
  ["pkgconfig"] {os-distribution = "centos" & os-version <= "7"}
  ["pkgconf-pkg-config"] {os-distribution = "mageia"}
  ["pkgconfig"] {os-distribution = "rhel" & os-version <= "7"}
  ["pkgconfig"] {os-distribution = "ol" & os-version <= "7"}
  ["pkgconf"] {os-distribution = "alpine"}
  ["pkg-config"] {os-distribution = "nixos"}
  ["pkgconf"] {os = "macos" & os-distribution = "homebrew"}
  ["pkgconfig"] {os = "macos" & os-distribution = "macports"}
  ["pkgconf"] {os = "freebsd"}
  ["pkgconf-pkg-config"] {os-distribution = "rhel" & os-version >= "8"}
  ["pkgconf-pkg-config"] {os-distribution = "centos" & os-version >= "8"}
  ["pkgconf-pkg-config"] {os-distribution = "ol" & os-version >= "8"}
  ["system:pkgconf"] {os = "win32" & os-distribution = "cygwinports"}
  ["pkgconf"] {os-distribution = "cygwin"}
]

depexts in Dune

Dune doesn't install depexts automatically as the Dune developers are a little nervous about running commands that would modify the global system state. This may change at some point, but for now Dune only provides support for listing the names of depexts, leaving it up to the user to install them as they see fit.

The dune show depexts command can be used to list the depexts of a project. For that command to work the project must have a lock directory. Here's an example of listing the depexts of a project:

$ dune pkg lock
...
$ dune show depexts
libao
libffi
pkgconf
sdl2

I ran these commands on a Mac with homebrew installed, so the package names are from the homebrew package repo. Each package listed there is one of the depexts of a package whose lockfile appears in the project's lock directory. Let's look at how this information is stored. Using pkg-config as an example:

$ cat dune.lock/conf-pkg-config.pkg
(version 4)

(build
 (run pkgconf --version))

(depexts pkgconf)

The relevant part for us is the depexts field. The current released version of Dune only stores the package's depexts for the system where dune pkg lock was run. The command dune show depexts simply concatenates the depexts fields from each lockfile in the lock directory.

When thinking about portable lock directories I always like to imagine what the experience would be using Dune for a project where the lock directory is checked into version control. I frequently switch between using two different machines for development - one running Linux and the other running MacOS. If I was to check in the lock directory I just generated on my Mac, and then check it out on Linux and continue development, dune show depexts would show me a list of packages for the wrong system!

Portable depexts in Dune

To make depexts portable, one's first instinct might be to use the same approach as taken with the depends field outlined in a previous post, listing the depexts for each platform for which the solver was run. Indeed such a change was added to the Dune Developer Preview when we first introduced portable lock directories, however we quickly realized a problem.

The depends, build, and install fields of a package rarely vary between OS distribution. It's reasonably common for those fields to be different on different OSes, but very rare for them to also be different on different OS distributions. As such, it's expected that users will elect to solve their projects for each common OS, but there would be little value in solving projects for each OS distro. In fact solving for multiple distros would slow down solving and bloat the lock directory, and users would somehow need to come up with a definitive list of distros to solve for.

But the depexts field is highly-dependent on the OS distro since package names are specific to the package repository for a particular distro. Recall that the depexts field in Opam package metadata lists package names along with the conditions under which that package name should be used, e.g.:

["pkg-config"] {os-family = "debian" | os-family = "ubuntu"}
["pkgconf"] {os-distribution = "arch"}
["pkgconf-pkg-config"] {os-family = "fedora"}
["pkgconfig"] {os-distribution = "centos" & os-version <= "7"}

These conditions almost always involve the name of the OS distro, and to make matters worse they also sometimes involve the OS version, as packages can change their names between different versions of the same OS. Evaluating these conditions at solve time for platforms with no distro or version specified tends to result in lockfiles with no depexts at all, since all the conditions evaluate to false.

The use case we have in mind for depexts in Dune is that a user will solve their project coarsely, usually just for each common OS with no consideration for distribution or version. Then when they run dune show depexts, the depexts will be listed using names appropriate to the current machine. This means Dune needs to store enough metadata about depexts to compute system-specific depext names at a later time. This means storing the same names and conditions as are currently stored in Opam files, and deferring evaluation of the conditions until as late as possible, such as right when dune show depexts is run.

The latest version of the Dune Developer Preview does just this; translating the depexts field from each package's Opam file into a Dune-friendly S-expression. After this change, the depexts field of conf-pkg-config's lockfile is:

$ cat dune.lock/conf-pkg-config.4.pkg
...
(depexts
 ((pkg-config)
  (or_absorb_undefined_var
   (= %{os_family} debian)
   (= %{os_family} ubuntu)))
 ((pkgconf)
  (= %{os_distribution} arch))
 ((pkgconf-pkg-config)
  (= %{os_family} fedora))
 ((pkgconfig)
  (and_absorb_undefined_var
   (= %{os_distribution} centos)
   (<= %{os_version} 7)))
 ((pkgconf-pkg-config)
  (= %{os_distribution} mageia))
 ((pkgconfig)
  (and_absorb_undefined_var
   (= %{os_distribution} rhel)
   (<= %{os_version} 7)))
 ((pkgconfig)
  (and_absorb_undefined_var
   (= %{os_distribution} ol)
   (<= %{os_version} 7)))
 ((pkgconf)
  (= %{os_distribution} alpine))
 ((pkg-config)
  (= %{os_distribution} nixos))
 ((pkgconf)
  (and_absorb_undefined_var
   (= %{os} macos)
   (= %{os_distribution} homebrew)))
 ((pkgconfig)
  (and_absorb_undefined_var
   (= %{os} macos)
   (= %{os_distribution} macports)))
 ((pkgconf)
  (= %{os} freebsd))
 ((pkgconf-pkg-config)
  (and_absorb_undefined_var
   (= %{os_distribution} rhel)
   (>= %{os_version} 8)))
 ((pkgconf-pkg-config)
  (and_absorb_undefined_var
   (= %{os_distribution} centos)
   (>= %{os_version} 8)))
 ((pkgconf-pkg-config)
  (and_absorb_undefined_var
   (= %{os_distribution} ol)
   (>= %{os_version} 8)))
 ((system:pkgconf)
  (and_absorb_undefined_var
   (= %{os} win32)
   (= %{os_distribution} cygwinports)))
 ((pkgconf)
  (= %{os_distribution} cygwin)))

That's a 1:1 translation of the depexts field from conf-pkg-config's Opam file. There's enough information there so that the appropriate package name can be computed on demand rather than just at solve time.

This bring us a step closer to a world where Dune users can check their lock directories into version control with confidence that their builds are reproducible across different platforms. To try out the latest version of the Dune Developer Preview, go to preview.dune.build.

Four months after the release of OCaml 5.3.0, the set of new features for the future version 5.4.0 of OCaml has been frozen. We are thus happy to announce the first alpha release for OCaml 5.4.0.

This alpha version is here to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun (see below for the installation instructions).

The progresses on stabilising the ecosystem are tracked on the opam readiness for 5.4.0 meta-issue.

The full release is expected around the end of July.

If you find any bugs, please report them on OCaml's issue tracker.

If you are interested in the ongoing list of new features and bug fixes, you can have a look at the changelog for OCaml 5.4.0.

Happy hacking, Florian Angeletti for the OCaml team

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.4.0~alpha1

The source code for the alpha is also available at these addresses:

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.4.0~alpha1+options <option_list>

where option_list is a space separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.4.0~alpha1+flambda+nffa ocaml-variants.5.4.0~alpha1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

Dune 3.19.0~alpha0 is now available. This alpha release includes several bug fixes and new features for OCaml developers.

Bug Fixes

This release addresses several issues that affected build reliability and functionality:

• Cram tests: Fixed duplicate execution of cram tests attached to multiple aliases
• pkg-config integration: Resolved missing --personality flag in pkgconfig invocations that prevented library detection in certain contexts
• Foreign libraries: Fixed evaluation of enabled_if conditions when computing stubs for foreign_library stanzas
• Preprocessing: Corrected dune describe pp behavior for libraries using (include_subdirs unqualified)
• Git integration: Fixed dune subst functionality in subdirectories of git repositories
• Windows compatibility: Resolved crash in Path.drop_prefix when using Melange on Windows

New Features

• Dependency validation: Added automatic detection and warnings for common typos in package dependency constraints
• Foreign library support: Added (extra_objects) field to (foreign_library) stanza with (:include) support

Improvements

• RPC server: Enhanced RPC server to handle build messages in eager watch mode and support concurrent builds

Installation

Install via opam:

opam install dune.3.19.0~alpha0

As this is an alpha release, please test thoroughly before using in production environments. Bug reports and feedback are welcome on the Dune issue tracker.

For the complete list of changes with pull request references, see the release notes.

Discuss this post on Discuss!

We've recently made a change to how lock directories work in the Dune Developer Preview.

Previously when Dune would solve dependencies for a project and generate a lock directory, the lock directory would be specialized for the computer where it was generated, with no guarantee it would work on a different computer. This posed a problem for checking lock directories into version control for projects with multiple developers, since one developer might lock the project on their Mac, say, only for another developer on Linux to be unable to build it due to its MacOS-specific lock directory.

This post is to announce that Dune now supports generating portable lock directories; a lock directory generated on one computer will now contain a dependency solution for a range of different computers, making it safe to check lock directories into version control.

Technical Details

In Opam the dependencies of a package can be different depending on properties of the computer where the package is being installed. A package might have a different set of dependencies when being installed on MacOS verses Linux versus Windows, or the dependencies might vary depending on the CPU architecture. It's even possible (though quite rare in practice) for the dependencies of a package to vary between operating system distributions, or even operating system versions.

This expressive power makes Opam very flexible as it allows packages to be specialized for the environment where they will be installed. The drawback of this approach is that there might not be a single solution to a dependency problem that works everywhere. Each combination of OS/architecture/distro/version could, in theory, require a different dependency solution. There are way too many combinations of those properties to run Dune's dependency solver once for each combination in a reasonable amount of time. Instead we elected to compromise and have Dune only generate a solution for common platforms by default, while allowing users to specify a custom list of platforms to solve for in their dune-workspace file.

Lockfiles now look a little different to account for the fact that they now contain multiple different platform-specific dependency solutions. For example, formerly, the lockfile for the ocaml-compiler package on an x86 machine running Windows, you might have had a depends field like:

(depends arch-x86_64 system-mingw mingw-w64-shims flexdll)

Most of these dependencies are specific to Windows; it's unlikely that you'll be able to install any of these dependencies on Linux or MacOS.

With the portable lock directories feature enabled, this field now might look like:

(depends
 (choice
  ((((arch x86_64)
     (os linux))
    ((arch arm64)
     (os linux))
    ((arch x86_64)
     (os macos)
     (os-distribution homebrew)
     (os-family homebrew))
    ((arch arm64)
     (os macos)
     (os-distribution homebrew)
     (os-family homebrew)))
   ())
  ((((arch x86_64)
     (os win32)
     (os-distribution cygwin)
     (os-family windows)))
   (arch-x86_64 system-mingw mingw-w64-shims flexdll))
  ((((arch arm64)
     (os win32)
     (os-distribution cygwin)
     (os-family windows)))
   (system-mingw mingw-w64-shims flexdll))))

This new syntax is similar to a match-statement, listing the dependencies for each platform for which Dune's solver ran. You can change the platforms Dune will solve for by adding something like this to dune-workspace:

(lock_dir
 (solve_for_platforms
  ((arch arm64)
   (os openbsd))
  ((arch x86_32)
   (os win32))))

After running dune pkg lock again, the lockfile for ocaml-compiler will be updated with these dependencies:

(depends
 (choice
  ((((arch arm64) (os openbsd))) ())
  ((((arch x86_32)
     (os win32)))
   (system-mingw ocaml-option-bytecode-only flexdll))))

A few other fields of lockfiles now also use the new syntax. Dune lockfiles contain the commands needed to build and install each package, as well as the names of any system packages needed by the Opam package, and each of these fields can also have platform-specific values.

Lockfile names now include the version number of the package. The ocaml-compiler package used to have a lockfile named ocaml-compiler.pkg but now has a name like ocaml-compiler.5.3.0.pkg instead. This is because it's possible that different platforms may require different versions of the same package in the dependency solution, so the lock directory needs to be able to contain multiple lockfiles for the same package without them colliding on filename.

How do I get it?

This feature is live in the latest version of the Dune Developer Preview. Follow the instructions on that page to install a version of Dune with this feature. With portable lock directories enabled, Dune will temporarily remain backwards compatible with the original lock directory format, though support will likely be dropped at some point. Generate a new lock directory by running dune pkg lock. You'll know your lock directory is portable if each file inside it has a version number in its filename.

Happy reproducible building!

This is the second alpha release of opam 2.4.0.

Binaries and full archive are signed by the opam dev team (fingerprint 92C5 26AE 50DF 3947 0EB2 911B ED4C F1CA 67CB AA92).

Please see our blog post for a highlight on the major changes and upgrade instructions.

This is the first alpha release of opam 2.4.0.

Binaries and full archive are signed by the opam dev team (fingerprint 92C5 26AE 50DF 3947 0EB2 911B ED4C F1CA 67CB AA92).

Please see our blog post for a highlight on the major changes and upgrade instructions.

OBuilder workers for FreeBSD have been updated to FreeBSD 14.2. See ocurrent/freebsd-infra

From today, ocaml-ci and opam-repo-ci will test against FreeBSD 14.2 rather than 14.1.

Following a post on discuss.ocaml.org, there has been a new release of ocurrent/ocaml-version that moves the minimum version of OCaml, considered as recent, from 4.02 to 4.08.

let recent = [ v4_08; v4_09; v4_10; v4_11; v4_12; v4_13; v4_14; v5_0; v5_1; v5_2; v5_3 ]

This change has far reaching side effects as OCaml-CI, opam-repo-ci, Docker base image builder among other things, use this to determine the set of versions of OCaml to test against. As these services are updated, testing on the old releases will be removed.

You can comment on this post on discuss.ocaml.org!

On behalf of the odoc team, I’m thrilled the announce the release of odoc 3.0.0 beta 1!

This release has been cooking for a long time - it’s been more than a year since odoc 2.4 landed, and a huge amount of work has gone into this. Thanks to the many others who contributed, either by code or by comments: @juloo, @panglesd, @EmileTrotignon, @gpetiot, @trefis, @sabine, @dbuenzli, @yawaramin, and more.

With this release we’re including a driver that knows how to use all of the exciting new features of odoc. This driver has been used to create the docs site for the various odoc tools.

Here are a selected set of features:

• Rendered source! Jump from any item in the documentation straight to its rendered source; no matter how much of OCaml’s complex module system you are using.
• Search by type! Our detective sherlodoc will find your lost value given its type.
• Convenient warnings! Warnings are now clearly visible and useful, no longer buried among your dependencies’ warnings.
• Self host your documentation, but link to ocaml.org for your dependencies.
• More sidebars! Odoc 3 features a global sidebar, allowing you to discover the most hidden corner of underground documentation.
• Image support! This cutting-edge feature now allows you to add images to your documentation. Video and audio come for free.
• Fully cross-package links! The OCaml docs are now a true spider web. Prepare to catch bugs, and eat them.
• Hierarchical documentation pages! We use a modular language. We don’t want a flat namespace for pages.
• The build dependencies are friendlier with incremental build systems, allowing better shared build caches.
• Quality of life improvements! Many improvements have been piling up since we started odoc 3. For instance: Add clock emoji before @since tag (@yawaramin, #1089)!

More explanation of these features is available at the odoc site, where we have documentation for authors, for users of odoc_driver, a cheatsheet, and differences from ocamldoc.

How can you help?

We need your feedback, both as authors and as users of documentation! Try things out using the new driver:

$ opam install odoc-driver    # don't forget to `opam update`
$ odoc_driver <package list>  # For instance: `$ odoc_driver brr odoc`
$ $YOUR_BROWSER _html/index.html

Many of those features’ implementations are not set in stone, but first versions. Please leave comments, either in this thread or as issues in the repository.

So, navigate already written documentation, and update your own docs to use the new features!

The release of OCaml 5.3.0 is imminent. As a final step, we are publishing a release candidate to check that everything is in order before the release in the upcoming week(s).

If you find any bugs, please report them on OCaml's issue tracker.

Compared to the second beta, this release candidate contains a regression fix in the type system (some type expressions were not generalized when they ought to be), one fix for the new check for dependency order at link time, and a manual update.

The full change log for OCaml 5.3.0 is available on GitHub. A short summary of the changes since the second beta release is also available below.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.3.0~rc1

The source code for the release candidate is also directly available on:

• GitHub
• OCaml archives at Inria

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.3.0~rc1+options <option_list>

where <option_list> is a space-separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.3.0~rc1+flambda+nffa ocaml-variants.5.3.0~rc1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

One month after the release of the first beta for OCaml 5.3.0, we are releasing a second and hopefully last beta release for OCaml 5.3.0 .

The most notable changes for this second beta are probably a handful of type system bugfixes. In particular, those fixes revert a change of behaviour in the first beta when pattern matching GADTs with non-injective type parameters.

We also have a C++ header compatibility fix and the restoration of some configuration variable in Makefiles for the sake of backward compatibility.

Overall, the release is converging and we are expecting to have a first release candidate around the middle of December. The progresses on stabilising the ecosystem are tracked on the opam readiness for 5.3.0 meta-issue.

Meanwhile, the second beta release of OCaml 5.3.0 is here to help you update your software and libraries ahead of the release (see below for the installation instructions).

The full release is expected before the end of December.

If you find any bugs, please report them on OCaml's issue tracker.

If you are interested in full list of features and bug fixes of the new OCaml version, the updated change log for OCaml 5.3.0 is available on GitHub.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.3.0~beta2

The source code for the beta is also available at these addresses:

• GitHub
• OCaml archives at Inria

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.3.0~beta2+options <option_list>

where option_list is a space separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.3.0~beta2+flambda+nffa ocaml-variants.5.3.0~beta2+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

Discuss this post on Discuss!

Dune can install and run developer tools in the context of a project. This feature is available in the Dune Developer Preview and in the upcoming release of Dune 3.17. As with all of Dune's package management features, consider this feature to be unstable as its UI and semantics may change without notice.

The currently supported tools are ocamllsp and ocamlformat. Dune has a new command dune tools exec <TOOL> -- [ARGS]... which downloads and installs the given tool, and then runs it with the given arguments (note the -- which separates arguments to dune from arguments to the tool). Tools are installed locally to the project, in its _build directory, which makes it easy to use different versions of a tool in different projects. An unfortunate consequence of installing tools into _build is that for the time being all tools are uninstalled whenever dune clean is run.

Let's see it in action:

$ dune tools exec ocamlformat -- --version
Solution for dev-tools.locks/ocamlformat:
- ocamlformat.0.26.2+binary-ocaml-5.2.0-built-2024-11-07.0-x86_64-unknown-linux-musl
    Building ocamlformat.0.26.2+binary-ocaml-5.2.0-built-2024-11-07.0-x86_64-unknown-linux-musl
     Running 'ocamlformat --version'
0.26.2

Precompiled Binaries

Note that in the example above, Dune's package solver chose to install version 0.26.2+binary-ocaml-5.2.0-built-2024-11-07.0-x86_64-unknown-linux-musl of ocamlformat. This packages comes from a new repository of binary packages containing pre-built executables for a select few Opam packages. Dune will search this repository in addition to the default repositories when solving packages for tools only (if a project has ocamlformat in its dependencies, the binary repository won't be searched while solving the project's dependencies).

The goal of the binary repository is to reduce the time it takes to get started working on a new project. Without it, Dune would need to build ocamlformat from source along with all of its dependencies, which can take several minutes.

For now only a small number of package versions are contained in the binary repository. To demonstrate, here's what happens if we run dune tools exec ocamlformat in a project with version=0.26.1 in its .ocamlformat file:

 $ dune tools exec ocamlformat -- --version
Solution for dev-tools.locks/ocamlformat:
- astring.0.8.5
- base.v0.17.1
- base-bytes.base
- base-unix.base
- camlp-streams.5.0.1
- cmdliner.1.3.0
...
- ocamlformat.0.26.1
...
    Building base-unix.base
    Building ocaml-base-compiler.5.1.1
    Building ocaml-config.3
    Building ocaml.5.1.1
    Building seq.base
    Building cmdliner.1.3.0
...
    Building ocamlformat.0.26.1
     Running 'ocamlformat --version'
0.26.1

Dune parses .ocamlformat to determine which version of ocamlformat to install, and 0.26.1 is not in the binary repo so it needed to be built from source.

If your project requires a version of a package not available in the binary repository, or you're on an operating system or architecture for which no binary version of a package exists, the package will be built from source instead. Currently the binary repository contains binaries of ocamlformat.0.26.2, ocaml-lsp-server.1.18.0 and ocaml-lsp-server.1.19.0 for x86_64-unknown-linux-musl, x86_64-apple-darwin and aarch64-apple-darwin.

Note that Linux binaries are statically linked with muslc so they should work on all distros regardless of dynamic linker.

Running ocamllsp

The program ocamllsp from the package ocaml-lsp-server analyzes OCaml code and sends information to text editors using the Language Server Protocol. The tool is crucial to OCaml's editor integration and it has a couple of quirks that are worth mentioning here.

TL;DR: Install Dune with the install script on the Developer Preview page and you'll get an ocamllsp shell script that will install and run the correct version of ocamllsp for your project.

Firstly the ocamllsp executable can only analyze code that has been compiled with the same version of the OCaml compiler as was used to compile the ocamllsp executable itself. Different versions of the ocaml-lsp-server package are incompatible with some versions of the OCaml compiler (e.g. ocaml-lsp-server.1.19.0 must be built with at least 5.2.0 of the compiler). This means that when Dune is choosing which version of ocaml-lsp-server to install it needs to know which version of the compiler your project is using. This is only known after the project has been locked (by running dune pkg lock), so Dune will refuse to install ocamllsp in a project that doesn't have a lock directory or for a project that doesn't depend on the OCaml compiler.

$ dune tools exec ocamllsp
Error: Unable to load the lockdir for the default build context.
Hint: Try running 'dune pkg lock'

The ocaml-lsp-server packages in the binary repository contain metadata to ensure that the ocamllsp executable that gets installed was built with the same version of the compiler as your project. For example the ocaml-lsp-server package built with ocaml.5.2.0 contains this line:

conflicts: "ocaml" {!= "5.2.0"}

This prevents it from being chosen if the project depends on any version of the compiler other than 5.2.0.

Another quirk is that ocamllsp will try to invoke the binaries ocamlformat and ocamlformat-rpc, both found in the ocamlformat package. The ocaml-lsp-server package doesn't depend on ocamlformat as the specific version of ocamlformat needed by a project is implied by the project's .ocamlformat file, which package managers don't consider when solving dependencies. This means that in general (whether using Dune or Opam for package management) it's up to the user to make sure that the correct version of ocamlformat is installed in order to use the formatting features of ocamllsp.

Otherwise expect this error in your editor:

Unable to find 'ocamlformat-rpc' binary. Types on hover may not be well-formatted. You need to install either 'ocamlformat' of version > 0.21.0 or, otherwise, 'ocamlformat-rpc' package.

Even if ocamllsp and ocamlformat are both installed by Dune, if you run dune tools exec ocamllsp you will find that ocamllsp still can't find the ocamlformat or ocamlformat-rpc executables. This is because unlike Opam, Dune does not install tools into your $PATH, and for the sake of simplicity, the dune tools exec <TOOL> command does not modify the environment of the tool it launches. This can be fixed by adding _build/_private/default/.dev-tool/ocamlformat/ocamlformat/target/bin (the directory containing ocamlformat and ocamlformat-rpc when ocamlformat is installed by dune) to the start of your $PATH variable before running dune tools exec ocamllsp. For example starting ocamllsp with the following shell script:

OCAMLFORMAT_TARGET="_build/_private/default/.dev-tool/ocamlformat/ocamlformat/target"

if [ ! -f $OCAMLFORMAT_TARGET/cookie ]; then
    # Make sure that the ocamlformat dev tool is installed as it's needed by
    # ocamllsp. There's currently no command that just installs ocamlformat so
    # we need to run it and ignore the result.
    dune tools exec ocamlformat -- --help > /dev/null
fi

# Add ocamlformat to the environment in which ocamllsp runs so ocamllsp can invoke ocamlformat.
export PATH="$PWD/$OCAMLFORMAT_TARGET/bin:$PATH"

# Build and run ocamllsp.
dune tools exec ocamllsp -- "$@"

Of course, it's rare to manually start ocamllsp directly from your terminal. It's normally launched by text editors. It would be impractical to configure your text editor to modify $PATH and run a custom command to start ocamllsp via Dune, and doing so would make it impossible to edit any project that doesn't use Dune for package management. Instead, the Dune Developer Preview ships with a shell script which installs ocamlformat and adds its bin directory to $PATH before launching dune tools exec ocamllsp. The script is simply named ocamllsp, and the Dune Developer Preview install script adds it to ~/.dune/bin which should already be in your $PATH if you're using the Developer Preview. The ocamllsp script also attempts to fall back to an Opam-managed installation of ocamllsp if it doesn't detect a Dune lockdir so the same script should work for non-Dune projects. Because the script is named the same as the ocamllsp executable, most editors don't require special configuration to run it. See the "Editor Configuration" section of the Dune Developer Preview page for more information about setting up your editor.

Some parts of the ocamllsp shell script may eventually make their way into Dune itself, but for the time being the shell script is the recommended way to launch ocamllsp for users of the Dune Developer Preview. The net result is that as long as your project has a lockfile, the first time you edit some OCaml code in the project Dune will download and run the appropriate version of ocamllsp.

The release of OCaml version 5.2.1 is imminent.

OCaml 5.2.1 is a collection of safe but import runtime time bug fixes backported from the 5.3 branch of OCaml. The full list of bug fixes is available above.

In order to ensure that the future release works as expected, we are planning to test a release candidate during the upcoming week.

If you find any bugs, please report them here on GitHub.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1:

opam update
opam switch create 5.2.1~rc1

The source code for the release candidate is available on

• GitHub
• Inria archives

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.2.1~rc1+options <option_list>

where <option_list> is a space-separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.2.1~rc1+flambda+nffa ocaml-variants.5.2.1~rc1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

One month and half after the release of the first alpha for OCaml 5.3.0, the release of OCaml 5.3.0 is drawing near.

The internal API of the compiler libraries has been frozen, and most core developer tools support (or will support soon) the new version of the compiler.

We have thus released a first beta version of OCaml 5.3.0 to help you update your software and libraries ahead of the release (see below for the installation instructions). More information about the whole release process is now available in the compiler repository.

Compared to the first alpha release, this beta contains a few runtime or typechecker fixes, a handful of fixes for the runtime event library and other miscellaneous fixes.

Exceptionally, this beta release also introduces a new flag -keywords for the compiler. This backward compatibility flag aims to help compiling old code that are using effect as a normal identifier, now that effect is a keyword in the new effect handler syntax.

The progresses on stabilising the ecosystem are tracked on the opam readiness for 5.3.0 meta-issue.

The full release is expected in the end of November or beginning of December, see the new prospective calendar for more information.

If you find any bugs, please report them on OCaml's issue tracker.

If you are interested in full list of features and bug fixes of the new OCaml version, the updated change log for OCaml 5.3.0 is available on GitHub.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.3.0~beta1

The source code for the beta is also available at these addresses:

• GitHub
• OCaml archives at Inria

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.3.0~beta1+options <option_list>

where option_list is a space separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.3.0~beta1+flambda+nffa ocaml-variants.5.3.0~beta1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

Feedback on this post is welcomed on Discuss!

We're happy to announce the first and hopefully only release candidate of opam 2.3.0.

This version does not have any significant change compared to the previous 2.3.0~beta2 release and we hope the final release to also have no significant change. Regardless, we invite users to test this version to make sure there isn't any regressions.

Unless a regression is spotted or another problem arises, we hope to have the final release of 2.3.0 out on the 12th of November.

Try it!

The upgrade instructions are unchanged:

1. Either from binaries: run

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.3.0~rc1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.3.0~rc1"

or download manually from the Github "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Please report any issues to the bug-tracker.

Happy hacking!

Discuss this post on Discuss!

Support for dune shell completions for bash and zsh has just landed in the Dune Developer Preview!

Running the installer adds a snippet to your shell config (e.g. ~/.bashrc) that installs a completion handler for dune. The completion script was taken from here, and that page has some information about how the script was generated. Once it's installed the completions will work any time dune is typed at the start of a command, so you can still use the completions when running a version of Dune installed with Opam or your system package manager after installing the Dune Developer Preview.

Currently only command completions are supported. So you can run:

$ dune c<TAB>
cache  clean  coq

...or:

$ dune build -<TAB>
--action-stderr-on-success
--action-stdout-on-success
--always-show-command-line
--auto-promote
--build-dir
--build-info
--cache
...

But if you run dune build <TAB> then it will still suggest local files rather than build targets.

Try it out!

Getting started is easy:

$ curl -fsSL https://get.dune.build/install | sh
$ source ~/.bashrc  # or: source ~/.zshrc
$ dune <TAB>
build
cache
clean
coq
describe
diagnostics
exec
...

Feedback on this post is welcomed on Discuss!

We're happy to announce the second beta release of opam 2.3.0.

As this version is a beta, we invite users to test it to spot previously unnoticed bugs as we head towards the stable release.

Changes

Compared to the previous 2.3.0~beta1 release, the main change is:

• Fix a regression in the detection of the current terminal size that leads to opam output that tries to fit itself into 80 columns regardless of the current terminal size (#6243).

• A NetBSD/x86_64 pre-built release binary is now available

You can view the full list of changes, including API changes, in the release note.

Try it!

The upgrade instructions are unchanged:

1. Either from binaries: run

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.3.0~beta2"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.3.0~beta2"

or download manually from the Github "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Please report any issues to the bug-tracker.

Happy hacking!

Feedback on this post is welcome on Discuss!

We're happy to announce the first beta release of opam 2.3.0. Compared to the previous 2.3.0~alpha1 release, you can view the full list of changes in the release note.

This version is a beta, so we invite users to test it to spot previously unnoticed bugs as we head towards the stable release.

Changes

• Fix an opam 2.1 regression where the initial pin of a local VCS directory would store untracked and ignored files. Those files would usually be cleaned before building the package; however, Git submodules would not be cleaned and would cause issues when paired with the new behaviour added in 2.3.0~alpha1, which makes an opam error when Git submodules fail to update (it was previously a warning). (#5809)

• Fix a regression which would make opam crash on platforms where getconf LONG_BIT is not available (e.g., OpenBSD). (#6215)

• Fix the installed packages internal cache, which was storing the wrong version of the opam file after a build failure. This could be triggered easily for users with custom repositories with non-populated extra-files. (#6213)

• Fix a regression in lint W59 with local URLs that are not archives. (#6218)

• Fix the compilation of opam on Windows with OCaml >= 5.0 (again)

• Several improvements to the prebuilt release binaries were made:

  • The Linux binaries are now built on Alpine 3.20
  • The FreeBSD binary is now built on FreeBSD 14.1
  • The OpenBSD binary is now built on OpenBSD 7.6 and loses support for OpenBSD 7.5 and older
  • A Linux/riscv64 binary is now available

API changes are denoted in the release note linked above. This release also includes a couple of PRs improving and extending the tests.

Try It!

The upgrade instructions are unchanged:

1. Either from binaries: run

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.3.0~beta1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.3.0~beta1"

or download manually from the GitHub "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Please report any issues to the bug-tracker.

Happy hacking!

Tarides' OCaml Infrastructure team has been hard at work over the last few months, focusing on improving the stability, reliability, and user experience of the OCaml ecosystem's core infrastructure. We are preparing for more substantive changes to come. We will have more fruit from this work to share soon, but updates on our efforts are overdue and we wanted to get you all caught up.

Platform Support

We've expanded and updated our platform support to keep pace with the evolving OCaml ecosystem:

• As part of the compiler release readiness, we've added support for OCaml 5.2 and the upcoming 5.3, currently in alpha.
• We're now publishing Windows Server 2022 Docker images to the OCaml Dockerhub. See for instance windows-server-msvc-ltsc2022-ocaml-4.14
• Dropped support for the post-LTS distro versions Debian 10 and 11, focusing our resources on the OCaml compiler's Tier 1 platform.

These updates ensure that our systems continue to support OCaml developers on a broad range of systems, in particular by testing package publication to the opam repository and publishing Docker images.

Opam Repository Publishing Experience

We've made improvements to enhance the experience of publishing packages to the opam repository:

• Implemented a linting check for package maintainer email addresses, ensuring package maintainers can be reliably contacted when needed.
• Mitigated solver timeout errors in the opam repo CI system, reducing frustrating delays in the package publishing process.
• Fixed an uncaught exception that sometimes occurred during linting checks in the opam repo CI.
• Improved error reporting and added instructions for running lint checks locally, making it easier for package authors to identify and resolve issues before submitting to the repository.
• We are generating documentation of the platforms under test in opam CI, allowing package authors a clear overview of the extensive build matrix we are providing.

We hope these changes will make package publication experience smoother. We're committed to improving the experience for newcomers and existing repository contributors alike, stay tuned for more improvements!

Security and Reliability

Maintaining the security and reliability of the OCaml infrastructure remains a top priority:

• Updated our systems to address CVE-2024-6387.
• We maintained 99.9% availability for the opam repo CI over the last two months, providing a stable and reliable service for the OCaml community.

Forging Ahead

Much has been done but much more is in the works! Expect updates more regularly going forward, and don't hesitate to reach out on ocaml/infrastructure/issues or discuss.ocaml.org if you have questions, requests, or ideas!

Related Changes

• Added continuous deployment for service configuration (by @mtelvers, https://github.com/ocurrent/ocurrent-configurator)
• Implemented linting for package maintainer email addresses (by @punchagan, https://github.com/ocurrent/opam-ci-check/pull/30)
• Mitigated solver timeout errors in opam repo CI (by @mtelvers and @shonfeder, https://github.com/ocaml/infrastructure/issues/147)
• Fixed uncaught exception in opam repo CI linting checks (by @shonfeder, https://github.com/ocurrent/opam-repo-ci/pull/341)
• Updated systems to address CVE-2024-6387 (by @mtelvers, https://github.com/ocaml/infrastructure/issues/140)
• Added support for OCaml 5.2 and 5.3 (by @mtelvers, https://github.com/ocurrent/opam-repo-ci/issues/268 and https://github.com/ocurrent/opam-repo-ci/issues/363)
• Improved Windows support (by @mtelvers, https://github.com/ocurrent/docker-base-images/issues/241)
• Added support for GCC 14 (by @mtelvers, https://github.com/ocurrent/docker-base-images/issues/279)
• Dropped support for Debian 10 and 11 (by @mtelvers and @shonfeder, https://github.com/ocurrent/ocaml-dockerfile/pull/220 and https://github.com/ocurrent/ocaml-dockerfile/pull/210)
• Generated documentation of CI test platforms and deployed services (by @benmandrew, https://github.com/ocurrent/opam-repo-ci/blob/master/doc/platforms.md and https://github.com/ocurrent/ocurrent-deployer/blob/master/doc/services.md)
• Improved error reporting and local lint check instructions in opam CI (by @punchagan, https://github.com/ocurrent/opam-repo-ci/issues/359 and https://github.com/ocurrent/opam-repo-ci/issues/360)

Hello folks! 👋

We'd like to welcome everyone to try and play with the Dune Developer Preview! 🎉

This experimental nightly release of dune includes a lot of improvements, including the much expected package management features, and it can be installed from that website or by using the new installation script:

$ curl -fsSL https://get.dune.build/install | bash

In a few seconds you should be ready to OCaml by calling dune:

You can also watch and share this demo on X and Mastodon.

Please try it out and let us know what you think 🙏

📅 You can book a feedback call with us here

📝 You can submit feedback using this form

🐛 You can submit issues to Github on ocaml/dune

Changes since last update

The Dune shared cache has been enabled by default. We're starting off by caching all downloads and dependencies.

We have improved support for dev tools. We're working to streamline this but in the latest binary you can:

• Configure your LSP (in Neovim, Vim, Emacs, etc) to call dune tools exec ocamllsp to get LSP support for your projects out of the box – this may take a little bit the first time it builds the LSP for a compiler version, but it's pretty much instant afterwards.

• Call dune fmt to get your project formatted – remember to add an .ocamlformat file if you don't have one yet. An empty one is enough.

• Call dune ocaml doc to get documentation built

What's next?

We're looking forward to streamlining the DX, working on better dependency locks, and looking into supporting Windows.

In particular, we're considering work on a few things:

• dune create <repo> – to let the community create templates that can be easily used from within dune
• dune pkg fetch – to prefetch packages and prepare a repository for working in offline mode
• dune build @deps - to build all dependencies, useful for staged builds in Dockerfiles
• dune pkg add <name> - to make adding packages straightforward
• a short-hand syntax for pins on github
• and more!

If you've got any ideas, we'd love to hear them, so please open a feature request on Github 🙏

Other updates

FunOCaml Presentation

At FunOCaml we had a last-minute opportunity to present the work being done on Dune and we used it to introduce the Developer Preview to the community, and even tested Package Management live with suggestions from the audience (thanks @anmonteiro and Paul-Elliot for participating!) – you can watch it on Twitch.

New design

We're working with @Claire_Vandenberghe on redesigning the Developer Preview website so that it'd feel like a seamless extension of OCaml.org – in this current iteration we've made it easier to get started and we're putting the FAQ front and center.

We'll be iterating on this design in the coming weeks until it fits perfectly within the OCaml.org design system 🎨

You can check the new website here: https://preview.dune.build

Upcoming Blog posts

In the near future we'll be publishing blog posts about the Developer Preview and Package Management, which we're working on with @professor.rose 👏

Four months after the release of OCaml 5.2.0, the set of new features for the future version 5.3.0 of OCaml has been frozen. We are thus happy to announce the first alpha release for OCaml 5.3.0.

This alpha version is here to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun (see below for the installation instructions). More information about the whole release process is now available in the compiler repository, and we will try to propagate this information to ocaml.org shortly.

The progresses on stabilising the ecosystem are tracked on the opam readiness for 5.3.0 meta-issue.

The full release is expected around November, see the new prospective calendar for more information.

If you find any bugs, please report them on OCaml's issue tracker.

If you are interested in the ongoing list of new features and bug fixes, the updated change log for OCaml 5.3.0 is available on GitHub.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.3.0~alpha1

The source code for the alpha is also available at these addresses:

• GitHub
• OCaml archives at Inria

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.3.0~alpha1+options <option_list>

where option_list is a space separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.3.0~alpha1+flambda+nffa ocaml-variants.5.3.0~alpha1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

Feedback on this post is welcomed on Discuss!

As mentioned in our talk at the OCaml Workshop 2024, we decided to switch to a time-based release cycle (every 6 months), starting with opam 2.3.

As promised, we are happy to announce the first alpha release of opam 2.3.0. You can view the full list of changes in the release note.

This version is an alpha, we invite users to test it to spot previously unnoticed bugs as we head towards the stable release.

Major breaking change

When loading a repository, opam now ignores files in packages' files/ directories which aren't listed in the extra-files field of the opam file. This was done to simplify the opam specification where we hope the opam file to be the only thing that you have to look at when reading a package specification. The optionality of the extra-files: field goes against that principle. This change also reduces the surface area for potential file corruption as it ensures that extra-files are checked against their checksums.

This is a breaking change and means that if you are using the files/ directory without the extra-files: field, you need to make sure that all files in that directory are listed in the extra-files field. Once done, the resulting opam file is backward-compatible and you don't need to worry about anything else.

If you have an opam repository, you should make sure all files are listed so every packages continues to work without any issue, which can be done automatically using the opam admin update-extrafiles command.

Major changes

• Packages requiring an unsupported version of opam are now marked unavailable, instead of causing a repository error. This means an opam repository can now allow smoother upgrade in the future where some packages can require a newer version of opam without having to fork the repository to upgrade every package to that version as was done for the upgrade from opam 1.2 to 2.0

• Add a new opam list --latests-only option to list only the latest versions of packages. Note that this option is respects the order options were given on the command line. For example: --available --latests-only will first list all the available packages, then choose only the latest packages in that set; while --latests-only --available will first list all the latest packages, then only show the ones that are available in that set

• Fix and improve opam install --check, which now checks if the whole dependency tree of the package is installed instead of only the root dependencies

• Add a new --verbose-on option to enable verbose output for specified package names. Thanks to @desumn for this contribution

• Add a new opam switch import --deps-only option to install only the dependencies of the root packages listed in the opam switch export file

• opam switch list-available will now not display compilers flagged with avoid-version/deprecated unless --all is given, meaning that the "trunk" build of OCaml no longer appears to be the latest version

• opam switch create --repos now accepts git URLs suffixed with .git instead of requiring the git+https:// protocol prefix. This is consistant with other commands such as opam repository add. Thanks to @Keryan-dev for this contribution

• opam switch set-invariant now displays the switch invariant using the same syntax as the --invariant flag

• The builtin-0install solver was improved and should now be capable of being your default solver instead of builtin-mccs+glpk. It was previously mostly only suited for automated tasks such as Continuous Integration. If you wish to give it a try, simply call opam option solver=builtin-0install

• Most of the unhelpful conflict messages were fixed

• Fix the value of the arch variable when the current OS is 32bit on a 64bit machine (e.g. Raspberry Pi OS)

• opam now fails when git submodules fail to update instead of ignoring the error and just showing a warning

• opam's libraries now compile with OCaml >= 5.0 on Windows

Various performance and other improvements were made and bugs were fixed. API changes are denoted in the release note linked above. This release also includes a handful of PRs improving the documentation and more two dozen PRs improving and extending the tests.

Try it!

The upgrade instructions are unchanged:

1. Either from binaries: run

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.3.0~alpha1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.3.0~alpha1"

or download manually from the Github "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Please report any issues to the bug-tracker.

Happy hacking!

As we prepare for the public beta, we're ramping up the DX interviews and ensuring the first few users will have a fun, productive experience with the Developer Preview.

📥 If you signed up for the Dev Preview back in May, check your inbox for a link and instructions to schedule your DX interview with us.

Here's a sample video on (Mastodon or X) where you can see us building the Riot project on a machine that does not have OCaml installed. It is pretty neat!

Seriously, big shoutout to the Dune team at Tarides[0] and Jane Street[1] who have been doing a phenomenal job 👏 ✨ 🐫

So here's what getting started with OCaml looks like using the Dune Developer Preview as of today (August 19 2024):

1. get dune from our binary distribution – we'll soon make this public!
2. run dune pkg lock in your favorite project
3. run dune build

That's it. No need to install anything else! Dune will see that lock file, fetch, and build all necessary dependencies.

🗺️ These are some strong steps towards the OCaml Platform vision for 2026 that we are actively working towards. If you have any thoughts or feedback please let us know!

There are more improvements coming that will help remove friction to get started and create a delightful experience. Both of these things we strongly believe will help onboard new users to the OCaml world.

Here's a few in the works:

• Various DX improvements – from new outputs to simplified workflows, we want to make using Dune just delightful.

• Bundled support for dev tools (OCamlFormat, odoc, LSP) – the default toolset will be available without any extra steps! Just call dune fmt and it works. No need to manually install anything else.

• Automatic dependency locking – when building, and even in watch mode, Dune will lock your dependencies by default and keep the lock up to date.

• Cross-project caching – by default we'll enable a local Dune cache across the system, so you never rebuild the same dependency, even across projects.

• Signed binaries with certificates of origin – we care deeply about security and want to make sure that any binary we ship can be easily verified and tracked back to its sources.

Stay tuned! 👋

PS: here's a longer video on (Mastodon or X) showing you the setup for OCaml from zero, creating a new project, and adding a dependency, all within ~5 minutes

[0] @emillon @Leonidas @gridbugs @tmattio @maiste . Ambre Suhamy, Alpha Diallo [1] @rgrinberg

Feedback on this post is welcomed on Discuss!

We are very excited to announce the first (and hopefully only) release candidate for opam 2.2.0.

We've squashed a few more bugs and we consider this to be ready for the final release. You can view the full list of changes in the release note.

We invite users to test it one final time just in case there are any previously unnoticed bugs!

Changes

• Fix opam upgrade wanting to keep rebuilding the compiler (as now it contains an x-env-path-rewrite field)
• Provide defaults so opam init -y no longer asks questions on Windows
• Fix OpamConsole.menu when there are more than 9 options (can happen on Windows)

A couple more improvements were made and bugs were fixed. The single API change is also denoted in the release note. This release also includes PRs extending the tests.

Try it!

In case you plan a possible rollback, you may want to first backup your ~/.opam or $env:LOCALAPPDATA\opam directory.

The upgrade instructions are unchanged:

1. Either from binaries: run

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.2.0~rc1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) }"

or download manually from the Github "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Please report any issues to the bug-tracker.

Thanks for trying this new release out, and we hope you will enjoy the new features of opam 2.2!

Feedback on this post is welcomed on Discuss!

We are very pleased to announce the third and final beta release of opam 2.2.0.

We've done our best to polish everything and squash as many bugs as possible in order to be ready for the final release. You can view the full list of changes in the release note.

This version is a beta, we invite users to test it to spot previously unnoticed bugs as we near the stable release.

Changes

• Greatly enhance the opam init user experience on Windows, and the number of recognised configurations
• New option opam init --cygwin-extra-packages=CYGWIN_PKGS --cygwin-internal-install, to specify additional packages for the internal Cygwin installation
• Redirect the opam root to C:\opamroot\opam-xxx when the opam root contains spaces on Windows
• Out-of-the-box UTF-8 paged --help on Windows
• Fix a performance regression when calling opam install --deps-only on an already installed package
• Fix several edge cases related to environment reverting
• Fixed some issues that could appear when upgrading from previous versions of opam
• Fix various issues with opam tree --with-test
• Fix parsing opam 2.1 switch import files containing extra-files
• Fix download URLs containing invalid characters on Windows
• Fix some failure cases when extracting tarballs which contain symlinks on Windows

Various other general and performance improvements were made and bugs were fixed. API changes are denoted in the release note. This release also includes PRs improving the documentation and improving and extending the tests.

Try it on Windows!

BEWARE: the command shown below is experimental, use caution and please do report any issues that you are experiencing. If you prefer to not use our experimental script, feel free to get the Windows binary directly from the Release Page and put it in your directory of choice instead.

Now that the Windows support was merged in opam-repository, testing is as simple as calling the following command from a PowerShell terminal:

Invoke-Expression "& { $(Invoke-RestMethod https://raw.githubusercontent.com/kit-ty-kate/opam/windows-installer/shell/install.ps1) }"

opening a new terminal, and a simple opam init will work out-of-the-box.

Try it on other platforms!

In case you plan a possible rollback, you may want to first backup your ~/.opam directory.

The upgrade instructions are unchanged:

1. Either from binaries: run

   bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.2.0~beta3"
   

   or download manually from the Github "Releases" page to your PATH.

2. Or from source, manually: see the instructions in the README.

You should then run:

opam init --reinit -ni

Please report any issues to the bug-tracker.

Thanks for trying this new release out, and we hope you will enjoy the new features!

The release of OCaml 5.2.0 is imminent. As a final step, we are publishing a release candidate to check that everything is in order before the release in the upcoming week(s).

If you find any bugs, please report them on OCaml's issue tracker.

Compared to the second beta, this release contains one small compiler-libs printer fix and one configuration tweak.

The full change log for OCaml 5.2.0 is available on GitHub. A short summary of the changes since the second beta release is also available below.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.2.0~rc1

The source code for the release candidate is also directly available on:

• GitHub
• OCaml archives at Inria

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.2.0~rc1+options <option_list>

where <option_list> is a space-separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.2.0~rc1+flambda+nffa ocaml-variants.5.2.0~rc1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.

Last week, we merged an update to the compiler-libs "shape" API for querying definition information from the compiler.

Unfortunately, this small change of API breaks compatibility with at least odoc. Generally, we try to avoid this kind of changes during the beta releases of the compiler. However, after discussions we concluded that it will be easier on the long term to fix the API right now in order to avoid multiplying the number of supported versions of the shape API in the various OCaml developer tools .

We have thus released a second beta version of OCaml 5.2.0 to give the time to developer tools to update their 5.2.0 version ahead of the release (see below for the installation instructions).

Beyond this changes of API, the new beta contains three more bug fixes and three documentation updates, which is a good sign in term of stability.

As usual, you can follow the last remaining compatibility slags on the opam readiness for 5.2.0 meta-issue.

If you find any bugs, please report them on OCaml's issue tracker.

Currently, the release is planned for the beginning of May.

If you are interested in full list of features and bug fixes of the new OCaml version, the updated change log for OCaml 5.2.0 is available on GitHub.

Installation Instructions

The base compiler can be installed as an opam switch with the following commands on opam 2.1:

opam update
opam switch create 5.2.0~beta2

The source code for the beta is also available at these addresses:

• GitHub
• OCaml archives at Inria

Fine-Tuned Compiler Configuration

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.2.0~beta2+options <option_list>

where option_list is a space-separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.2.0~beta2+flambda+nffa ocaml-variants.5.2.0~beta2+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.