Versions and support
This page states how versions are chosen, what a released version line receives, and how changes reach it. The workspace version is 0.1.0, and the first stable release is still being prepared; the Downloads page lists the artifacts when it lands. The Requirements and distributions page carries the per-platform requirement facts.
Version numbering
Versions follow semantic versioning as MAJOR.MINOR.PATCH. One
workspace version is the single source of truth: the Android, iOS, React
Native, and WebAssembly packages are all stamped from it at release
time, so one version string identifies one core.
The SDK is pre-1.0. The FFI contract is addition-only, so existing members keep their signature and meaning across an upgrade. Packaging can still change while the release is 0.x: an artifact-set change or a renamed target bumps the minor version, and a pre-1.0 minor may break a build even when the contract did not change. Treat a minor upgrade as one to test, not one to assume.
Pin exact versions
Release archives are immutable and carry the version in the file name,
for example rustic-maps-sdk-android-vX.Y.Z.aar. Keep the exact version
you validated against and upgrade deliberately. The version you pin also
names the notices file that accompanies it.
Two release tracks
| Track | What it is | What it means for you |
|---|---|---|
| Stable | A vX.Y.Z tag and its release assets | The version to ship; the support statements on this page apply to it |
| Preview | A pre-release tag (vX.Y.Z-rc.N) from the same workflow, marked as a pre-release | Evaluation only; a preview is superseded by the stable release of the same version |
Tags are never moved, and a broken release is superseded by a new tag; the failed release’s assets and checksums stay.
Support window
Each released minor line is intended to receive fixes for a stated window after the next minor line releases. That window length is not yet fixed and is published here with the first stable release. Until it is published, plan to upgrade to the newest minor line for fixes.
Deprecation
The contract’s addition-only rule means a released contract member keeps its signature and meaning; a new release adds members rather than removing them. A deprecation can still mark a member or a packaging detail as superseded, and it is announced in the release notes and the changelog before the release that retires it. The exact deprecation lead time is not yet fixed and is published here with the first stable release.
Checking the loaded version
The compiled SDK answers get_sdk_compiled_version on every surface.
Compare it with the artifact you shipped. A mismatch means the loaded
core and your dependency declaration disagree, and a diagnostics screen
should show the value.
Getting support
Report a problem through the project’s issue tracker with four things:
the get_sdk_compiled_version output, your platform and operating
system version, the exact SDK version you pinned, and a minimal
reproduction. For a rendering problem, include the TileFrameStatistics
of an affected frame. For a provider problem, include the SdkError
variant and its verbatim detail.