Why Alpha, Beta, and RC Come Before ConnectOnion 1.7 LTS

ConnectOnion will keep the 1.6 line stable while the next feature train moves through 1.7.0aN, 1.7.0bN, and 1.7.0rcN before 1.7.0 becomes stable and long-term supported.

The question that exposed the problem

We wanted to validate a large set of ACP and coding-agent features before calling ConnectOnion 1.7 stable. A tempting plan was to ship those experiments as 1.6.1, 1.6.2, and 1.6.3, then rename the result 1.7.0 after the bugs were gone.

The numbers would show progress, but they would make the wrong promise. A patch says that it is a compatible maintenance update for the stable line. Normal Python upgrades consider that patch, so unfinished 1.7 behavior would turn stable users into preview testers without their consent.

Two release lanes, one clear promise

1.6.0 ─────→ 1.6.1 ─────→ 1.6.2
stable fixes   stable fixes   stable fixes

       1.7.0a1 → 1.7.0a2 → 1.7.0b1 → 1.7.0rc1 → 1.7.0
       incomplete preview   feature complete   stable / LTS

Why this protects existing users

A normal upgrade stays on stable releases:

python -m pip install --upgrade connectonion

A developer has to opt into a published preview:

python -m pip install --pre --upgrade connectonion

An exact pin such as connectonion==1.7.0a1 is also an explicit choice. The first preview was published on August 11, 2026. PyPI and the GitHub Prerelease carry the same wheel and source archive hashes. The latest stable GitHub Release remains 1.6.0, so publishing the alpha did not move normal users onto 1.7.

What the 1.7 train is validating

The product theme is one complete coding-agent and Agent Client Protocol experience:

• delegate coding work to Claude and Codex;
• track tasks and structured results;
• stop, resume, and recover sessions;
• stream ordered ACP updates and final agent messages;
• approve tools and switch modes without losing session state;
• connect authorized MCP servers;
• keep the Python host, React SDK, and chat UI compatible with the same events.

How we keep the scope understandable

The 1.7.0 milestone contains feature issues and release gates. The integration checklist contains the exact PR inventory, cross-repository dependencies, and phase evidence.

We deliberately do not add every implementation PR to the milestone. Counting both a feature issue and its implementation PRs makes progress look larger without making the remaining work clearer.

Publication is part of the engineering work

A release is not complete when the code merges. The exact artifact must pass its gates, publish through PyPI Trusted Publishing, install cleanly, and appear in a GitHub Release. Only then does the documentation site advertise that exact version.

Release notes say what changed. The design journal records:

• the problem and alternatives;
• the decision and tradeoffs;
• the evidence that supports it;
• what would make us revisit it.

From now on, every meaningful feature-train launch, phase promotion, stable release, or architecture change will create or substantially update a design journal entry. Small maintenance patches stay in release notes unless they teach a reusable lesson. That keeps the journal useful instead of filling it with duplicate changelog pages.

The rule we will carry forward

Stable users should never become experiment participants because maintainers wanted a convenient sequence of numbers. Preview users should know exactly what promise they are accepting. Maintainers should be able to point to one public record of why a release was shaped this way.

That is why ConnectOnion 1.7 starts with an alpha, earns its way through beta and RC, and becomes LTS only after the experience is proven.