mirror of
https://github.com/HKUDS/nanobot.git
synced 2026-06-15 15:24:06 +00:00
docs: remove nightly branch guidance
This commit is contained in:
parent
8fe0149c65
commit
6e6470daa0
@ -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
|
||||||
|
|
||||||
|
|||||||
4
.github/workflows/ci.yml
vendored
4
.github/workflows/ci.yml
vendored
@ -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 }}
|
||||||
|
|||||||
@ -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
|
||||||
|
|
||||||
|
|||||||
@ -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
|
||||||
|
|||||||
10
README.md
10
README.md
@ -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)!
|
||||||
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user