# Roadmap

> What Brine has done so far, what is planned for backends, GPUs, proofs and tools, and how versions work before and after 1.0.

Source: https://docs.brinelang.org/reference/roadmap/

Brine is young: version 0.4.0, with a self-hosted compiler that builds itself on every CI run on Linux, macOS and Windows. Until 1.0, any minor release (0.x) may change the language; 1.0 will mean a stable language and ABI, and there is a lot to do before then. The order below is a plan, not a promise.

## Next

[Section titled “Next”](#next)

The next steps, from the Brine README:

* **Mach-O output**, so macOS on Apple silicon gets native dev builds.
* **A built-in linker**, so builds don’t need a C toolchain.
* **Arrays kept on the GPU** between constructs.
* **AMD and Intel GPUs** through Vulkan.
* **Quantifiers in contracts**: `forall i in 0..n: a[i] >= 0`.
* **An LSP server** and **a package manager**.

## Done

[Section titled “Done”](#done)

| Version | What it brought                                                                                                                                                                                                                                                                                                                                               |
| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0.1     | The core language: structs and methods, enums and `match`, generics, `Option`/`Result` and `?`, tuples, arrays, maps, strings with methods and slices, f-strings, `for a, b in`, `enumerate`, file and process I/O, modules. Contracts and the prover. The `par` constructs and `world`. Tests, the CLI, `fmt`, `explain`, `guide`. The self-hosted compiler. |
| 0.2     | The Brine IR. The native x86-64 backend (COFF and ELF). C generated from the IR, in parallel translation units cached one by one.                                                                                                                                                                                                                             |
| 0.3     | Unicode-aware string methods. Nested tuple unpacking. `print` with `sep=` and `end=`. The compiler parses and proves in parallel. Unwind tables in native code.                                                                                                                                                                                               |
| 0.4     | GPU offload (CUDA and Metal) with results identical to the CPU’s. Deterministic reduction order. The native AArch64 backend for Linux. Native debug builds with DWARF and gdb pretty-printers. Prebuilt releases and one-line installers. Faster native code, strings and allocation.                                                                         |

The [changelog](/reference/changelog/) has every change.

## Planned

[Section titled “Planned”](#planned)

### Backends

[Section titled “Backends”](#backends)

* **Mach-O objects**, so macOS on Apple silicon gets native dev and debug builds instead of going through C.
* **CodeView debug info**, for Visual Studio and WinDbg.
* **Register allocation and optimization passes on the IR**, so native builds get closer to optimized C.
* **A built-in linker and a prebuilt runtime**, so builds don’t need a C toolchain at all.
* **SIMD.**
* **MSVC support** in the C backend.

### GPUs

[Section titled “GPUs”](#gpus)

* **Arrays kept on the device** between constructs. Today every launch copies the arrays a body reads to the GPU and the ones it writes back, so constructs that do little work per byte (a plain sum of an array) stay on the CPU.
* **`par(...)` forks and nested constructs** on the GPU.
* **AMD and Intel GPUs**, once there is hardware to test on: Vulkan compute with SPIR-V kernels (the driver loaded at run time, as CUDA is), exactly rounded `/` and `sqrt` in the kernels, a capability check for denormals and f64, and a self-test kernel at startup that turns the GPU off if its results differ from the CPU’s. NVIDIA GPUs and lavapipe (Mesa’s CPU Vulkan) can test most of it, but not each vendor’s own shader compiler, so it waits for real devices. This includes the AMD and Intel GPUs in Intel Macs: Metal is used only on Apple GPUs for now.

### WebAssembly

[Section titled “WebAssembly”](#webassembly)

[WebAssembly builds](/tooling/webassembly/) (`--target wasm` and `web`) are on Brine’s main branch, not yet in a release. Next:

* **Threads** (wasi-threads, Web Workers), so `par` runs in parallel there too. Today it runs in order on one thread.
* **Files in the browser.**
* **A playground page** that runs the compiler itself in the browser. The compiler already builds for WebAssembly: its generated C for itself is byte-identical to the native compiler’s.

### Proofs

[Section titled “Proofs”](#proofs)

* **Generic bodies checked once** against constraints, rather than once per instance.
* **Quantifiers in specs**: `forall i in 0..n: a[i] >= 0`.
* **Reasoning about array contents.**
* **Nonlinear facts** such as `i * j`.
* **Counterexamples** when a proof fails.

### Tools

[Section titled “Tools”](#tools)

* **An LSP server**, for editors.
* **`brine fix`**, which applies the machine-applicable fixes diagnostics already carry in `--json` output.
* **A package manager** (`brine add`).
* **`brine launch --hosts`**, to start a multi-machine `world` run (today you set `BRINE_RANK`, `BRINE_WORLD_SIZE` and `BRINE_PEERS` yourself; see [Environment variables](/tooling/environment-variables/#brine_rank-brine_world_size-brine_peers)).

## Versions

[Section titled “Versions”](#versions)

Brine follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html). The version is set in one place in the compiler, and every release is a tagged commit with notes in the [changelog](/reference/changelog/).

| Release       | Means                                                                                                                                                                 |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0.x.0 (minor) | new features or **breaking changes**: the language, the CLI or the results of a program may change. Breaking changes are marked in the changelog with how to migrate. |
| 0.x.y (patch) | fixes only                                                                                                                                                            |
| 1.0.0         | a stable language and ABI: from then on, breaking changes only in a new major version                                                                                 |

Versions move one step at a time, and only the maintainer decides when 1.0 happens. Pre-releases are tagged with a `-` (like `v0.5.0-rc.1`) and marked as such on GitHub.

Until 1.0, pin the version you build with (`BRINE_VERSION=0.4.0` for the [installers](/tooling/environment-variables/#installer-variables)) and read the changelog before upgrading.

## Related

[Section titled “Related”](#related)

* [Changelog](/reference/changelog/)
* [Design and architecture](/reference/design/)
* [Platforms](/reference/platforms/#coming-next)