Roadmap & Release Cycle Plans
(Last update: June 16th, 2021)
This is a living document that defines our current roadmap and explains our future release cycle plans for the upcoming years.
Please be aware that our roadmap will only discuss major changes, and might be adapted during planning phases.
All roadmap related discussions, proposals and changes for specific roadmap tasks can either be found in the ReScript Forum, or in dedicated GitHub PRs / issues.
Add M1 support (see first call for testing)
Add support for unicode strings (e.g
Add opt-in configuration flag
stdlib-futureto disable OCaml related stdlib code (for writing future proof code; see discussion)
(breaking) Remove OCaml’s Format module (should have no impact on the majority of ReScript users; see discussion)
Infix operator support (only for a dedicated set of math operators
%, etc.; see the tracking issue)
Docstring syntax support:
/** */instead of
@ocaml.doc("My docstring")(tracking issue)
Convert stdlib files (
Belt, etc) to ReScript syntax (tracking issue)
bsconfig.jsonjson compliant (Proposal)
Some other less prominent enhancements (will be mentioned in the Changelog later on)
(Non exhaustive list of changes; goals may be adapted)
Estimated release date for v10: Mid of January 2022
Important: These changes are currently listed on the roadmap, but may be subject to change before development starts.
Removal of ocaml stdlib
PPX only allowed on top level packages?
Removal of recursive modules?
Estimated start of development: May 2022
Estimated switch to v12: Mid of January 2023
Feature set of
Additional features will be discussed during the
Will be discussed during
We will follow a similar approach to the NodeJS project and consider even version numbers to be stable releases (v10, v12, v14,...), and uneven version numbers as experimental (v11, v13, v15,...) releases.
The goal of the new release system is to have a slower and easier to manage upgrade experience for our users / library maintainers, with a proper grace-period to discuss and refine feature proposals.
The experimental release channel will be useful for gathering feedback / testing out migrations without the fear of breaking our existing userbase whenever more intrusive changes have been made.
Even version number (v10, v12, v14,...)
A stable version is guaranteed to be supported for a 1 year lifespan, splitting up in an active development phase, and an maintenance phase. The maintenance phase starts as soon as the work for the next experimental release has been started and will mostly cover critical bugfixes.
A stable release will eventually require some initial migration. We will provide proper upgrade guides between each stable version.
During active development, there are no breaking changes within the compiler (no changes in runtime representation, behavior of the build system, configuration names etc.).
No removal of language features
During the active development phase, there may be non-breaking minor releases (e.g. v10.1.0). For example:
New configuration flags
Stdlib additions / Library enhancements
Regular bugfix releases for the compiler, build system, stdlib, etc.
Docs will be synced up with the latest stable release
Uneven number (v11, v13, v15,....)
Development phase of around 6 months. After that it will potentially turn into the next stable release (e.g. v11 -> v12)
Introduces a planned set of breaking changes based on the previous stable release
Acts as a stepping stone to reach more ambitious goals in a next stable release
The list of breaking changes will be discussed before the work is being started
No guaranteed stability / support during experimental development. The compiler toolchain will be reliable as always, but the proposed feature set might change
Docs might or might not be available during experimental changes
npm install rescript@latest
Latest experimental (in case we are in an "experimental" dev phase):
npm install rescript@next
On every new stable release, the previous stable release will be frozen and will only receive critical bugfix updates in a best effort service.
That doesn't mean that older stable versions go stale; in practise those releases will be pretty robust and reliable, so upgrading codebases can be done at your own pace.
We will make sure that there are well documented upgrade paths between each stable release.