# How is the RLM Project Versioned? A Two-Layer Strategy Explained

> Understand RLM project versioning with its two-layer strategy. Learn how a public package version and an internal training library version work together.

- Repository: [az/rlm](https://github.com/alexzhang13/rlm)
- Tags: internals
- Published: 2026-06-18

---

**RLM uses a dual versioning scheme where the public package version `0.1.2` is declared in [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml) following PEP 621 standards, while an internal training library maintains a separate `__version__` constant set to `"0.1.0"` in [`training/src/rlm_train/__init__.py`](https://github.com/alexzhang13/rlm/blob/main/training/src/rlm_train/__init__.py).**

The alexzhang13/rlm repository implements a clear separation between its public API distribution and internal training components. This architecture allows the training sub-package to evolve independently while maintaining stable metadata for Python packaging tools.

## The Two-Layer Versioning Architecture

RLM organizes its version identifiers across three key files, creating distinct layers for public distribution and internal development.

### Public Package Version in [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml)

The canonical version that pip, PyPI, and `importlib.metadata` report lives in the `[project]` table of [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml):

```toml
[project]
name = "rlms"
version = "0.1.2"

```

According to the source code at [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml), this **PEP 621-compliant** declaration defines the official release version for the entire distribution. This is the value that downstream tools and dependency resolvers use when specifying version constraints.

### Internal Training Library Version

Isolated within the training sub-package, [`training/src/rlm_train/__init__.py`](https://github.com/alexzhang13/rlm/blob/main/training/src/rlm_train/__init__.py) defines a private version constant:

```python
__version__ = "0.1.0"

```

This internal identifier is not exposed through the public package metadata. It allows the training library to iterate independently from the main package releases, ensuring that experimental changes to training scripts do not trigger unnecessary version bumps for the core library.

### Top-Level Package Structure

The main entry point at [`rlm/__init__.py`](https://github.com/alexzhang13/rlm/blob/main/rlm/__init__.py) re-exports core objects but **deliberately omits** a `__version__` attribute. This design choice forces consumers to query the package metadata rather than importing version constants directly, ensuring they always receive the accurate PEP 621 version regardless of how the package was installed.

## How to Check the RLM Version Programmatically

You can retrieve the current version using two different methods depending on which component you need to inspect.

**Method 1: Query the public package (recommended)**

```python
import importlib.metadata

pkg_version = importlib.metadata.version("rlms")
print(f"RLM package version: {pkg_version}")

# → RLM package version: 0.1.2

```

**Method 2: Access the training sub-package directly**

```python
from rlm_train import __version__ as train_version
print(f"RLM training library version: {train_version}")

# → RLM training library version: 0.1.0

```

Both approaches work immediately after installing the repository in editable mode (`uv pip install -e .`).

## Why RLM Uses Separate Version Identifiers

This two-layer approach provides several architectural benefits:

- **Isolation of concerns**: The training library can receive bug fixes and feature additions without forcing a new release of the core package
- **Standards compliance**: Using [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml) for the public version ensures compatibility with modern Python packaging tools and metadata inspection
- **Clean API surface**: By omitting `__version__` from the top-level `rlm` module, the project avoids version synchronization issues between source files and package metadata

## Summary

- **Primary version**: `0.1.2` declared in [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml) under the `[project]` table
- **Internal version**: `"0.1.0"` defined as `__version__` in [`training/src/rlm_train/__init__.py`](https://github.com/alexzhang13/rlm/blob/main/training/src/rlm_train/__init__.py)
- **Retrieval method**: Use `importlib.metadata.version("rlms")` for the official package version
- **Design rationale**: Separation allows the training library to evolve independently while maintaining PEP 621 compliance for distribution

## Frequently Asked Questions

### What is the current version of RLM?

The current public release is version **0.1.2**, as defined in the `version` field of [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml). However, the internal training library located at [`training/src/rlm_train/__init__.py`](https://github.com/alexzhang13/rlm/blob/main/training/src/rlm_train/__init__.py) maintains its own version constant set to **"0.1.0"**.

### Why does the training library have a different version number?

The training library version is decoupled from the main package to allow independent iteration. Since the training scripts in `training/src/rlm_train/` are considered implementation details rather than public API, they can be updated frequently without triggering unnecessary version bumps for the core `rlms` package distributed via PyPI.

### How should I retrieve the RLM version in my code?

Always use `importlib.metadata.version("rlms")` to query the version dynamically. This method reads directly from the package metadata installed in your environment, ensuring you receive the accurate `0.1.2` version regardless of whether you installed from PyPI or a local checkout. Avoid hardcoding version strings or importing from internal modules.

### Does RLM follow semantic versioning?

While the [`pyproject.toml`](https://github.com/alexzhang13/rlm/blob/main/pyproject.toml) version `0.1.2` uses a three-component numbering scheme compatible with semantic versioning, the repository does not explicitly document a SemVer policy. The presence of major version 0 indicates the package is in initial development, where APIs may change without strict backward-compatibility guarantees.