When copying an example, keep its whole application folder and its package URLs together. The folder supplies neighboring modules; the URLs select the library version. The release notes tell you which Roc compiler tested that combination.
Published examples§
A release’s roc-time-examples-<version>.zip contains complete applications whose time and optional zones dependencies point at immutable packages. Download it from the releases page when you want to target that version.
The daily compatibility workflow tests the latest published release against the latest Roc nightly. If a new compiler breaks an older package, check the workflow result and available patch releases. Existing release URLs don’t change; adopting a fix means updating your package URL.
Roc files don’t pin the compiler. Starting with the compiler named in the release notes gives you the tested combination; later nightlies need their own compatibility check.
Core and optional zone data§
The release notes identify the core and zone-data packages. The core is enough for explicit-offset timestamps, interval algebra and calendar calculations. Add the data package for named zones.
A data update can change how a future local meeting resolves. Existing in-memory interpretations keep their original rules; explicitly resolve again when you want the new rules. The interpretation context source demonstrates both choices.
Saving an IXDTF declaration records its supported text and annotations, not the rules used to interpret it. Supply the appropriate context when loading it. A zone name and version identify a snapshot; they don’t authenticate an arbitrary transition table or fetch one for you.
The repeated local time example also shows why a local timestamp alone can’t record every choice: selecting the first occurrence, the last occurrence or the whole repeated range gives different results.
Development examples§
Repository examples import the working-tree packages by relative path. Run them from a complete checkout with a current Roc nightly. They can use APIs added after the latest release; copying a new module name into an old release’s header won’t make that API available.
The manual links to current source for browsing. For matching executable examples and function signatures, follow your release’s archive and API links.
When upgrading§
Read the target release’s notes and API changes.
Copy the relevant package URLs from its archive. Start with its tested compiler or verify your later nightly.
Update your application’s dependencies and keep any example companion modules you copied.
Run the application with the date, precision and clock-change cases that matter to it.
Each release also has a tested HTML/PDF manual and compiler-generated API archive. Historical API URLs stay stable. The pinned native renderer builds the manual without a package compiler; that doesn’t change which compiler your application needs.