docs: add release information to README.md

[MegaRedHand]

This PR adds release information to the readme. It also adds the formal verification effort to the list of incoming features.

[github-actions]

🤖 Kimi Code Review

This is a documentation-only PR with no code changes. The updates are clear and correctly formatted.

README.md (lines 94-102): The "Container Releases" section provides useful deployment information. The table formatting is valid Markdown.

README.md (line 125): The new roadmap item links correctly to issue 272 and maintains consistency with the existing list format (using the [Description](URL) pattern).

No issues identified. The documentation accurately describes the container tagging strategy and appropriately extends the roadmap.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

[github-actions]

🤖 Claude Code Review

This is a documentation-only PR. Here's my review:

---

Review: docs: add release information to README.md

This is a clean, low-risk documentation PR. The changes are correct and useful, but there are a few minor consistency issues worth noting.

Observations

Redundancy with existing content

The new ### Container Releases section (lines 94–102) partially duplicates information already present in ### Older devnets (line 114):

Docker tags for each devnet are released, with format devnetX (i.e. devnet1, devnet2, devnet3).

The new table already explains devnetX format. The ### Older devnets section now reads as a partial repeat. Consider either merging the two into the new Container Releases section, or removing the overlapping sentence from ### Older devnets.

"currently running devnet" is time-sensitive

Line 101:

| `latest` | Alias for the stable image of the currently running devnet |

"Currently running devnet" will become stale whenever the active devnet changes. A phrasing like "Alias for the most recent stable devnet image" would age better.

Section hierarchy feels slightly off

### Container Releases is a subsection under ## Current status, but it describes release tagging — which is more of a deployment/operations concern than a status of client features. It might fit better as its own ## Container Releases top-level section, or merged under a ## Running the client or ## Releases section. Minor point — this is subjective.

New roadmap item (line 125)

The formal verification entry is a straightforward addition, correctly linked to the tracking issue. No issues here.

Summary

Functionally correct. The main actionable suggestion is addressing the redundancy between the new Container Releases table and the existing ### Older devnets section, and softening the time-sensitive phrasing of the latest tag description.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[greptile-apps]

Greptile Summary

This PR adds a "Container Releases" section to the README documenting the Docker image tagging strategy (devnetX, latest, unstable), and appends formal verification of the STF to the incoming features list. Both changes are accurate and consistent with the existing devnet release documentation already present in the file.

Confidence Score: 5/5

Safe to merge — documentation-only change with no code impact.

All changes are documentation updates to README.md. Content is accurate, consistent with existing sections, and no P0/P1 findings were identified.

No files require special attention.

Important Files Changed

Filename	Overview
README.md	Adds "Container Releases" section with Docker tag table and appends formal verification to the incoming features list; content is accurate and well-formatted.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[CI build on merge to main] --> B[ghcr.io/lambdaclass/ethlambda:unstable]
    B -->|tested & promoted| C[ghcr.io/lambdaclass/ethlambda:devnetX]
    C --> D[ghcr.io/lambdaclass/ethlambda:latest]

Loading

_{Reviews (1): Last reviewed commit: "docs: add release information to readme" | Re-trigger Greptile}

[github-actions]

🤖 Codex Code Review

1. README.md introduces container-tag semantics that do not match the documented release process, which can mislead operators about which client build they are running. In README.md:96-README.md:102, latest is described as “the stable image of the currently running devnet” and unstable as a promotion source. That conflicts with RELEASE.md:21-RELEASE.md:35, which says latest is simply the latest image built from main, and with .github/workflows/docker_publish.yaml:4-.github/workflows/docker_publish.yaml:10 and .github/workflows/docker_publish.yaml:87-.github/workflows/docker_publish.yaml:102, where tags are free-form workflow inputs and no unstable/promotion behavior is enforced. I would either align the README wording with the current workflow or update the workflow/docs together in the same change.

No Rust, consensus, SSZ, signature, or fork-choice code is touched here, so I found no code-correctness or security issues in the client itself. Residual risk is documentation drift only.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt