docs: remove nightly branch guidance

This commit is contained in:
chengyongru 2026-06-08 11:23:19 +08:00 committed by Xubin Ren
parent 8fe0149c65
commit 6e6470daa0
5 changed files with 26 additions and 61 deletions

View File

@ -18,7 +18,7 @@ Channels and providers are allowed to repeat similar logic (send retries, media
## Minimal change that solves the real problem ## Minimal change that solves the real problem
Fix bugs by changing only what is necessary. Do not bundle unrelated refactors or clean-ups into a feature or bugfix PR. If a refactor is genuinely required, it should be a separate PR targeting `nightly`. Fix bugs by changing only what is necessary. Do not bundle unrelated refactors or clean-ups into a feature or bugfix PR. If a refactor is genuinely required, it should be a separate, clearly scoped PR.
## Keep PRs reviewable ## Keep PRs reviewable

View File

@ -2,9 +2,9 @@ name: Test Suite
on: on:
push: push:
branches: [main, nightly] branches: [main]
pull_request: pull_request:
branches: [main, nightly] branches: [main]
concurrency: concurrency:
group: ${{ github.workflow }}-${{ github.ref }} group: ${{ github.workflow }}-${{ github.ref }}

View File

@ -61,9 +61,9 @@ Messages flow through an async `MessageBus` (`nanobot/bus/queue.py`) that decoup
- Security boundaries: [`.agent/security.md`](.agent/security.md) - Security boundaries: [`.agent/security.md`](.agent/security.md)
- Common gotchas: [`.agent/gotchas.md`](.agent/gotchas.md) - Common gotchas: [`.agent/gotchas.md`](.agent/gotchas.md)
## Branching Strategy ## Contribution Flow
See [`CONTRIBUTING.md`](./CONTRIBUTING.md) for the full two-branch model (`main` vs `nightly`) and PR guidelines. See [`CONTRIBUTING.md`](./CONTRIBUTING.md) for contribution flow and PR guidelines.
## Code Style ## Code Style

View File

@ -14,42 +14,30 @@ software together: with care, clarity, and respect for the next person reading t
Maintainers are community stewards who help review, organize, and maintain the project. The list below describes each maintainer's current open-source project responsibilities. Maintainers are community stewards who help review, organize, and maintain the project. The list below describes each maintainer's current open-source project responsibilities.
| Maintainer | Focus | | Maintainer | Role |
|------------|-------| |------------|------|
| [@re-bin](https://github.com/re-bin) | Project lead, `main` branch | | [@re-bin](https://github.com/re-bin) | Project lead; reviews community PRs and handles merges |
| [@chengyongru](https://github.com/chengyongru) | `nightly` branch, experimental features | | [@chengyongru](https://github.com/chengyongru) | Reviews community PRs and may approve them; merges are handled by the project lead |
## Branching Strategy ## Contribution Flow
We use a two-branch model to balance stability and exploration: ### What Should I Open a PR For?
| Branch | Purpose | Stability | PRs are welcome for:
|--------|---------|-----------|
| `main` | Stable releases | Production-ready |
| `nightly` | Experimental features | May have bugs or breaking changes |
### Which Branch Should I Target?
**Target `nightly` if your PR includes:**
- New features or functionality - New features or functionality
- Refactoring that may affect existing behavior
- Changes to APIs or configuration
**Target `main` if your PR includes:**
- Bug fixes with no behavior changes - Bug fixes with no behavior changes
- Documentation improvements - Documentation improvements
- Minor tweaks that don't affect functionality - Minor tweaks that don't affect functionality
- Refactoring that is clearly scoped and easy to review
- Changes to APIs or configuration, when the impact is documented
**When in doubt, target `nightly`.** It is easier to move a stable idea from `nightly` For riskier or larger changes, please open an issue or draft PR early so the
to `main` than to undo a risky change after it lands in the stable branch. shape of the work can be discussed before the implementation grows too large.
### Starting Work ### Starting Work
Before making changes, sync the target branch and create a topic branch from it. Before making changes, sync your local checkout and create a topic branch.
For stable bug fixes and documentation-only changes, start from the latest `main`.
For experimental work, start from the latest `nightly`.
```bash ```bash
git fetch upstream git fetch upstream
@ -65,28 +53,6 @@ Keep unrelated local changes out of the topic branch. If your checkout already h
work in progress, use a separate worktree or finish that work before starting a work in progress, use a separate worktree or finish that work before starting a
new branch. new branch.
### How Does Nightly Get Merged to Main?
We don't merge the entire `nightly` branch. Instead, stable features are **cherry-picked** from `nightly` into individual PRs targeting `main`:
```
nightly ──┬── feature A (stable) ──► PR ──► main
├── feature B (testing)
└── feature C (stable) ──► PR ──► main
```
This happens approximately **once a week**, but the timing depends on when features become stable enough.
### Quick Summary
| Your Change | Target Branch |
|-------------|---------------|
| New feature | `nightly` |
| Bug fix | `main` |
| Documentation | `main` |
| Refactoring | `nightly` |
| Unsure | `nightly` |
## Development Setup ## Development Setup
Keep setup boring and reliable. The goal is to get you into the code quickly: Keep setup boring and reliable. The goal is to get you into the code quickly:
@ -106,9 +72,9 @@ pytest
ruff check nanobot/ ruff check nanobot/
# Format code — optional. The existing tree predates `ruff format`, # Format code — optional. The existing tree predates `ruff format`,
# so running it across `nanobot/` produces a large unrelated diff # so running it broadly produces large unrelated diffs.
# (E501 is ignored, so many existing lines exceed the 100-char setting). # Do not mix mechanical formatting churn into a functional PR.
# Format only files you've actually touched, not the whole package. # Use formatting only for the exact code your change intentionally touches.
ruff format <files-you-changed> ruff format <files-you-changed>
``` ```
@ -137,6 +103,9 @@ In practice:
- Async: uses `asyncio` throughout; pytest with `asyncio_mode = "auto"` - Async: uses `asyncio` throughout; pytest with `asyncio_mode = "auto"`
- Prefer readable code over magical code - Prefer readable code over magical code
- Prefer focused patches over broad rewrites - Prefer focused patches over broad rewrites
- Do not mix mechanical formatting, line wrapping, import sorting, or quote churn
into a feature or bugfix PR. If formatting cleanup is needed, make it a
separate formatting-only PR.
- If a new abstraction is introduced, it should clearly reduce complexity rather than move it around - If a new abstraction is introduced, it should clearly reduce complexity rather than move it around
## Modifying CI Workflows ## Modifying CI Workflows

View File

@ -316,14 +316,10 @@ Browse the [repo docs](./docs/README.md) for the latest features and GitHub deve
PRs welcome! The codebase is intentionally small and readable. 🤗 PRs welcome! The codebase is intentionally small and readable. 🤗
### Branching Strategy ### Contribution Flow
| Branch | Purpose | See [CONTRIBUTING.md](./CONTRIBUTING.md) for setup, review, and contribution
|--------|---------| guidelines.
| `main` | Stable releases — bug fixes and minor improvements |
| `nightly` | Experimental features — new features and breaking changes |
**Unsure which branch to target?** See [CONTRIBUTING.md](./CONTRIBUTING.md) for details.
**Roadmap** — Pick an item and [open a PR](https://github.com/HKUDS/nanobot/pulls)! **Roadmap** — Pick an item and [open a PR](https://github.com/HKUDS/nanobot/pulls)!