Roadmap
Table of Contents
Summary
ORE Studio is built in public, milestone by milestone. Today the project is in its first release series, working towards v1.0 — Static World: a release that can reproduce every ORE sample perfectly, end to end, from a standing start. After that comes v2.0 — Dynamic World, where time starts to move — ticking market data, live pricing, and trade lifecycles. This page explains that journey in plain terms; the linked pages carry the detail.
Where we are going
The destination is fixed by the product identity: a learning environment for quantitative finance, built on ORE and QuantLib, that gives developers a database, a GUI, and an orchestration layer through which to explore how computational finance actually works. The identity page is the durable statement of what the product is and is not — the roadmap below is how we get there in stages.
Each stage is a milestone: a named major release with its own theme, mission, and definition of done. The full catalogue lives on the Milestones page; the journey so far and next is:
v1.0 — Static World (in progress)
Time stands still. The world is a snapshot, and the goal is to reproduce it perfectly: ingest any ORE sample, persist every input and output in the database, execute the full pipeline inside ORE Studio, and produce results bit-for-bit identical to the ORE reference outputs — with GUI coverage for every data operation. The correctness bar is the ORE reference implementation itself.
See Milestone v1.0 — Static World for the mission and definition of done.
v2.0 — Dynamic World (planned)
Time starts to move. Market data ticks, trades transition through their lifecycle, curves bootstrap live, and pricing screens update as data arrives. Where v1.0 proves correctness against a static snapshot, v2.0 proves it in a live environment.
See Milestone v2.0 — Dynamic World for the mission and definition of done.
Where we are now
We are in Version 0 — the 0.x.x release series working towards
v1.0. Every sprint cuts an incremental build (0.0.18 is the latest
at the time of writing; see Versions for the running series and
GitHub releases for downloads). The architectural tiers are standing
— Postgres persistence, a service layer, a Qt GUI, CLI and shell
front-ends — and reference data is being commissioned through them
type by type, with ORE sample round-trips as the proof of
correctness.
When v1.0's definition of done is met — every ORE sample loads,
executes, and round-trips with zero diff — Version 0 closes, 1.0.0
is cut, and work moves to the next series.
How to read the plan
Two documents structure all forward-looking work, and this page deliberately repeats neither:
- Milestones own the what and why — identity, theme, mission, and definition of done for each major release target.
- Versions own the how and when — the release series, the sprints within them, and the incremental builds they produce.
Timelines are deliberately coarse — v1.0 carries a horizon of months, v2.0 of years — because ORE Studio is a learning-driven project, not a delivery commitment. The day-to-day truth of what is being worked on right now is always in the current sprint under Agile.
See also
- Product identity — what ORE Studio is and is not.
- Milestones — the major release targets in full.
- Versions — the release series and their sprints.
- Agile — how the rolling work is organised.