EnerOS v0.1.0

Release Date: January 15, 2024 Codename: Genesis Git Tag: v0.1.0 Support Status: Internal Preview Total Crates: 1 Test Cases: 32

Version Overview

EnerOS v0.1.0 “Genesis” is the first milestone version of the EnerOS project, marking the official launch of a Power/Energy-Native AgentOS for the power and energy domain. The core objective of this version is to establish the Cargo workspace engineering skeleton, define the eneros-core crate prototype, and establish the directory structure and collaboration process for subsequent version iterations. EnerOS chose Rust as the sole implementation language because critical power system infrastructure has stringent requirements for memory safety, concurrency safety, and deterministic latency, and Rust’s ownership model, zero-cost abstractions, and no-runtime GC characteristics precisely match these demands.

v0.1.0 does not introduce any power-domain-specific functionality, but focuses on “laying a solid foundation”: unified code style (rustfmt + clippy), commit conventions (Conventional Commits), CI pipeline (GitHub Actions), issue/PR templates, code of conduct, and MIT open-source license. These engineering infrastructure elements may seem mundane, but they are prerequisites for the subsequent 56 crates and 7300+ test cases to evolve in coordination. All code in this version has been validated by both cargo fmt --check and cargo clippy -- -D warnings, ensuring consistent code style for subsequent contributors.

As the “Genesis” version, v0.1.0 established the three design principles of EnerOS: First, Power-Native — domain concepts such as grid topology, power flow equations, and physical constraints must be built-in as first-class kernel citizens, not external libraries; Second, Agent-First — all business logic is carried by Agents, and the operating system provides Agent scheduling, communication, and governance capabilities; Third, Open Source — using the MIT license, welcoming power companies, research institutions, and individual developers to participate together. These three principles will run through all subsequent versions of EnerOS.

Key Data

New Features

1. Cargo Workspace Engineering Skeleton

Establish the EnerOS top-level Cargo workspace, with eneros-core as the first member crate. The workspace uses unified dependency version management (Cargo.toml’s [workspace.dependencies]), ensuring all crates share the same version of tokio, serde, tracing, and other foundational dependencies, avoiding version fragmentation.

// Root Cargo.toml
[workspace]
members = [
    "crates/eneros-core",
]
resolver = "2"

[workspace.dependencies]
tokio = { version = "1.35", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
thiserror = "1.0"
anyhow = "1.0"

The workspace also configures a unified profile optimization strategy:

[profile.release]
opt-level = 3
lto = "fat"
codegen-units = 1
panic = "abort"
strip = true

[profile.dev]
opt-level = 0
debug = true

2. eneros-core Crate Prototype

eneros-core is the kernel crate of EnerOS, defining the most basic types, constants, and utility functions. v0.1.0 provides only a minimal viable API surface, leaving room for gradual expansion in subsequent versions.

// crates/eneros-core/src/lib.rs
//! EnerOS Core Library
//!
//! Provides the most basic type definitions and utility functions for the EnerOS operating system.

#![forbid(unsafe_code)]
#![warn(missing_docs)]

pub mod version;
pub mod constants;
pub mod error;

/// EnerOS version information
pub const VERSION: &str = "0.1.0";

/// EnerOS codename
pub const CODENAME: &str = "Genesis";

/// Returns EnerOS version information
pub fn version() -> &'static str {
    VERSION
}

/// Returns EnerOS codename
pub fn codename() -> &'static str {
    CODENAME
}

Version information module:

// crates/eneros-core/src/version.rs
use serde::{Deserialize, Serialize};

/// EnerOS version number, following semantic versioning
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct Version {
    pub major: u32,
    pub minor: u32,
    pub patch: u32,
    pub pre: Option<String>,
}

impl Version {
    pub fn new(major: u32, minor: u32, patch: u32) -> Self {
        Self { major, minor, patch, pre: None }
    }

    pub fn parse(s: &str) -> Result<Self, ParseVersionError> {
        // Simplified semantic version parsing
        let parts: Vec<&str> = s.splitn(2, '-').collect();
        let nums: Vec<&str> = parts[0].split('.').collect();
        if nums.len() != 3 {
            return Err(ParseVersionError::InvalidFormat);
        }
        Ok(Version {
            major: nums[0].parse()?,
            minor: nums[1].parse()?,
            patch: nums[2].parse()?,
            pre: parts.get(1).map(|s| s.to_string()),
        })
    }
}

3. Basic Project Structure

Establish the standard directory structure for the EnerOS repository; all subsequent crates, documentation, and tests are organized according to this structure:

eneros/
├── Cargo.toml              # Workspace root configuration
├── Cargo.lock
├── LICENSE                 # MIT license
├── README.md
├── CONTRIBUTING.md
├── CODE_OF_CONDUCT.md
├── .github/
│   ├── workflows/
│   │   └── ci.yml          # CI pipeline
│   ├── ISSUE_TEMPLATE/
│   └── PULL_REQUEST_TEMPLATE.md
├── crates/
│   └── eneros-core/        # First crate
│       ├── Cargo.toml
│       ├── src/
│       │   ├── lib.rs
│       │   ├── version.rs
│       │   ├── constants.rs
│       │   └── error.rs
│       └── tests/
│           └── integration.rs
├── docs/                   # Design documents
└── examples/
    └── hello_eneros.rs     # Getting started example

Core directory usage description:

4. MIT License and Open Source Governance

EnerOS uses the MIT license, allowing commercial use, modification, distribution, re-licensing, and private use, with only the requirement to retain copyright notices. The reason for choosing MIT over Apache-2.0 is: the power industry supply chain includes many small and medium-sized equipment manufacturers, and the simplicity of MIT reduces legal review costs.

// crates/eneros-core/Cargo.toml
[package]
name = "eneros-core"
version = "0.1.0"
edition = "2021"
license = "MIT"
authors = ["EnerOS Contributors"]
description = "Core library for EnerOS, a Power/Energy-Native AgentOS"
repository = "https://github.com/eneros/eneros"
homepage = "https://eneros.org"
keywords = ["power-systems", "energy", "agent-os", "rust"]
categories = ["os", "science"]

[dependencies]
serde = { workspace = true }
serde_json = { workspace = true }
thiserror = { workspace = true }

Improvements

Since this is the first version, there are no “improvements”. The following lists the engineering specifications established in v0.1.0 as the baseline for subsequent versions:

• Code style: Enforce rustfmt + clippy, clippy -D warnings in CI blocks warnings from being merged
• Commit conventions: Use Conventional Commits (feat:, fix:, docs:, refactor:, etc.)
• Branch strategy: main branch is protected, must pass CI and at least 1 person Code Review
• Release process: Release triggered by Git Tag, auto-generate CHANGELOG
• Documentation requirements: All pub items must have doc comments, #![warn(missing_docs)] enforced

Bug Fixes

First version has no historical bugs. The following are issues found and fixed during development:

• Fixed dependency conflict warning caused by resolver not being set to 2 in Cargo.toml (#3)
• Fixed issue where cargo test in CI pipeline did not enable --all-features (#5)
• Fixed path separator inconsistency in examples/hello_eneros.rs on Windows (#8)
• Fixed badge links in README.md pointing to wrong branch (#11)

Breaking Changes

None. The first version does not involve any backward compatibility issues.

Performance Improvements

First version has no performance baseline comparison. The following is the performance benchmark established in v0.1.0 (benches/core_bench.rs), as a reference point for subsequent versions:

// benches/core_bench.rs
use criterion::{black_box, criterion_group, criterion_main, Criterion};
use eneros_core::version::Version;

fn bench_version_parse(c: &mut Criterion) {
    c.bench_function("version_parse", |b| {
        b.iter(|| Version::parse(black_box("0.1.0")).unwrap())
    });
}

fn bench_version_new(c: &mut Criterion) {
    c.bench_function("version_new", |b| {
        b.iter(|| Version::new(black_box(0), black_box(1), black_box(0)))
    });
}

criterion_group!(benches, bench_version_parse, bench_version_new);
criterion_main!(benches);

Benchmark results (debug build):

Contributors

v0.1.0 was completed by the EnerOS founding team, with 3 contributors in total:

Thanks to all community members who participated in the first version discussions and Code Reviews.

Upgrade Guide

v0.1.0 is the first version of EnerOS, no upgrade from older versions is needed. The following are the steps to use EnerOS for the first time:

Environment Requirements

Installation Steps

# 1. Clone the repository
git clone https://github.com/eneros/eneros.git
cd eneros

# 2. Install rustup (if not installed)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# 3. Build the project
cargo build --release

# 4. Run tests
cargo test --all

# 5. Run the example
cargo run --example hello_eneros

Hello EnerOS Example

// examples/hello_eneros.rs
use eneros_core::{version, codename};

fn main() {
    println!("================================");
    println!("  Welcome to EnerOS!");
    println!("  Version : {}", version());
    println!("  Codename: {}", codename());
    println!("================================");
    println!("Power/Energy-Native AgentOS");
    println!("Licensed under MIT");
}

Example output:

================================
  Welcome to EnerOS!
  Version : 0.1.0
  Codename: Genesis
================================
Power/Energy-Native AgentOS
Licensed under MIT

Next Steps

v0.1.0 is only the starting point. v0.2.0 “Foundation” will be released within this month, introducing the kernel abstraction layer, syscall interface, and error code system. It is recommended to focus on the following areas:

• Read the design RFCs in the repository’s docs/ directory
• Participate in architecture discussions on GitHub Discussions
• Contribute through the good first issue label