Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: align runtime crate version with runtime release version #1389

Merged
merged 1 commit into from
Dec 3, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,11 +87,15 @@ For key management and validator rewards, consult our [validator guide online](h

## Versioning

### Historical Versioning (Up to `v5.44.0`)

Up to the release `v5.44.0`, **Astar** releases contained both the client & the runtime blobs.
In general, each release contained both, with some specific releases (related to fixes) which only released e.g. client or runtime.
Standard semantic versioning approach was used.

The new approach will see the split of client & runtime releases.
### New Versioning Approach (From `v5.45.0`)

Starting with v5.45.0, the release process has been split into separate client and runtime releases, each following distinct versioning schemes:

The **client release** will continue to follow semantic versioning, continuing where the former approach left off.
E.g. the next expected minor release will be `v5.45.0`.
Expand All @@ -101,6 +105,8 @@ The **runtime release** will follow a new versioning approach - `runtime-XXYY`.
* The `XX` part will be a number of 2 or more digits, starting with **10**, and will be incremented by **1** each time a new runtime release is made. E.g. `runtime-1000` will be followed by `runtime-1100`, which will be followed by `runtime-1200`, and so on. This is like a combination of _major_ and _minor_ semver versions.
* The `YY` part will always be a 2 digit number, and serves as a _patch_ semver version. E.g. if we have `runtime-1000` and need to release a fix, the new release version will be `runtime-1001`.

The runtime crate version will align its major and minor versions with the Rust crate version, while the patch version will always remain `00`. For example, a runtime release for `runtime-1100` corresponds to the Rust runtime crate version `11.0.0`. A minor runtime release such as `runtime-1101` corresponds to the Rust runtime crate version `11.1.0`.

## Workspace Dependency Handling

All dependencies should be listed inside the workspace's root `Cargo.toml` file.
Expand Down
Loading