[NOTICE] main frozen for dora 1.0 consolidation

[heyong4725]

dora-rs/dora is frozen for 1.0 consolidation (2026-04-17 → ~2026-07-31)

The main branch of this repo is under branch protection while the dora-rs/adora → dora-rs/dora consolidation lands as dora 1.0. Non-critical PRs will hold until the freeze lifts at Phase 5c (GA tag).

Critical security patches: ping @heyong4725 directly. We can land CVE-level fixes during the freeze with admin bypass.

Tracking: Consolidation execution epic · Plan document

Expected lift: Phase 5c tag of v1.0.0 (revised to ~2026-07-31 from the prior ~2026-06-01 estimate — consolidation is taking longer than planned; see #1624 draft PR for current status). Updated 2026-06-22.

[EthanFrostpro]

really glad to see this heading toward 1.0. been watching the adora → dora consolidation from the sidelines and the phased approach makes a lot of sense for something this complex. the dataflow pipeline model is genuinely one of the cleaner ways i've seen to handle multi-modal robotics data compared to ROS2's more traditional pub/sub. quick question - after the freeze lifts will there be a migration guide for folks who built on the pre-1.0 API? or is the plan to keep backward compat through the transition?

[heyong4725]

Thanks @EthanFrostpro — short answer: yes to both, and for app code it's mostly a no-op.

For app developers (node/operator code + YAML + CLI):

Your existing pre-1.0 code should compile and run against 1.0 with little-to-no change:

• Rust node/operator APIs — dora-node-api, dora-operator-api trait signatures and imports unchanged. Crate names unchanged (no rename, same Cargo.toml entries).
• Python node API — imports stay the same (from dora import Node). PyO3 surface is additive.
• C / C++ node APIs — apis/c/node and apis/c++/node headers and symbols preserved.
• YAML dataflow descriptor — most 0.x descriptors work unchanged. A few fields gained new defaults or small renames, documented in yaml-spec.md.
• CLI commands you already use — dora run / build / start / stop / list / logs / new etc. preserved.

Migration guide

docs/migration-from-0.x.md covers what to do if you hit one of the smaller breaks. Today it's a minimum-viable scaffold; full per-API before/after examples land as a Phase 5c exit criterion (validated on fork examples + at least one external volunteer repo before GA).

If you want to stress-test your existing pre-1.0 app against the 1.0 RC and report back, I'll add you to the volunteer list — real-world feedback directly shapes the final guide.

New in 1.0 (ignore if not needed)

Most of these are additive features that came over from the adora fork. Pre-1.0 app code doesn't need to touch any of them to keep working:

• Service pattern (request/reply), action pattern (goal/feedback/result), streaming chunks
• Record/replay (dora record, dora replay)
• Parameters (dora param), topic inspection (dora topic)
• Fault tolerance: restart_policy, max_restarts, input_timeout, health_check_timeout
• Distributed multi-daemon deployments
• Cross-language type system with strict-type validation
• CUDA IPC via ctypes (no more numba dependency)

Treat these as "available when you want them," not as migration work.

On the dataflow-vs-pub/sub point

Agreed — that's the thesis. Service + action patterns in 1.0 round it out for request-reply and long-running ops without giving up the strict-typed dataflow backbone. See docs/patterns.md for when to reach for which.

[phil-opp]

Just to clarify: You pushed a lot of changes to main after this announcement. Was this by mistake? Or is the main branch only frozen for external contributions?

[heyong4725]

@phil-opp not a mistake, and fair to call out the ambiguity in the freeze notice at the top of this issue. The short answer: main is frozen for external contributions and for new-feature work, not for rc.1 → GA stabilization. The original notice wasn't specific enough about that distinction. I'll amend it.

What's actually happening

docs/plan-dora-1.0-consolidation.md §5 describes a Phase 5b "RC stabilization + dogfood" window between tagging v1.0.0-rc.1 (landed 2026-04-17, commit 145ccce0) and tagging v1.0.0 (GA). The commits phil-opp is pointing at are that window.

Intent: harden rc.1 into rc.2 → ... → GA. No new features, no API changes, no new subsystems.

What's landed

47 commits since 2026-04-17. Breakdown by type (from git log --since=2026-04-17 --oneline main):

• ~28 test: / qa: / ci: commits — test coverage (fault-tolerance contracts for max_restarts, input_timeout, health_check_timeout, NodeRestarted+InputRecovered; semantic contracts for service/action/streaming/validated-pipeline; cross-language Rust↔Python payload tests); CI reliability (shared cache, nightly issue filing per-job, cargo check --examples gate); QA tooling (qa-deep/qa-nightly/qa-release-gate/qa-mutation-audit local ladder).
• ~10 fix: commits — bugs surfaced during stabilization: dora record /tmp cargo resolution, dora node add/remove docs, CLI --detach race, dora stop name-or-UUID acceptance, daemon bench_support mutation exclusion, smoke-script bash 3.2 compat, etc. All bounded-scope bug fixes, no new behavior.
• ~6 refactor: commits — internal cleanups enabling the fixes above: BuildConfig struct replacing 12 positional params on dora_cli::build(), BuildConfig::from_str_args helper for the PyO3 bindings, CLI working_dir override plumbing, canonicalize_working_dir + working_dir_or_parent helper extraction. Zero API break to external users of dora-cli / dora-node-api / dora-operator-api.
• ~3 docs: commits — in-tree doc updates (capability-to-test matrix, agentic QA policy, contributor cheat sheet).

None of these would belong in a 0.x release. They belong in the pre-1.0.0 RC window specifically because they harden what rc.1 already shipped.

Review discipline

Every one of the 47 commits went through:

1. Pre-commit local gates (make qa-fast at minimum, make qa-deep for anything touching coordinator/daemon).
2. /review before opening the PR.
3. PR review comment cycle (most PRs had at least one round of reviewer feedback; several had multiple).
4. Admin-squash-merge via gh pr merge --admin, consistent with the "admin bypass for critical patches" clause, extended to Phase 5b work by intent but not explicitly documented in the notice.

PR descriptions, commit messages, and reviewer replies are all public. If any specific PR looks out of scope for a stabilization window, point at it and I'll explain or revert.

What external contributors should expect

Still frozen for them until Phase 5c (GA tag). PRs from outside the consolidation team will hold. If someone has a CVE-level patch, the notice says to ping me directly — that part is unchanged.

Fix to the notice

Updating the top-of-issue text to be explicit about the external-vs-internal distinction. Thanks for catching the ambiguity.

[heyong4725]

Heads up: the consolidation freeze is being extended to ~2026-06-01 — about two weeks past the original estimate. Phase 5c GA work is still in flight; see #1624 for current status.

The PR rescue stream is still active and lands daily under admin bypass when changes are panel-faithful to existing community work. If you have a stalled PR that's affected, ping in-thread and we'll triage.