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

RLM uses a dual versioning scheme where the public package version 0.1.2 is declared in 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.

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

The canonical version that pip, PyPI, and importlib.metadata report lives in the [project] table of pyproject.toml:

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

According to the source code at 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 defines a private version constant:

__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 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)

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

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 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 under the [project] table
• Internal version: "0.1.0" defined as __version__ in 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. However, the internal training library located at 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}