erigontech / erigontech/erigon
Docs: the v3.6 versioning/deploy transition is not automatic — track the required work
- Dominant language
- Go
- Stars
- 3.6k
- Forks
- 1.5k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 455
Description
## Summary
When `release/3.6` is cut and `v3.6.0` is released, the documentation site (docs.erigon.tech, Docusaurus on GitHub Pages) will **not** automatically archive v3.5 or switch its default to v3.6. The transition is a set of manual edits mirroring #22062 + #22063, and `main`'s versioning state is currently stale. This issue tracks that work and flags a couple of transition-window hazards.
Note: cutting the `release/3.6` branch by itself changes nothing on the live site — `main` has no deploy workflow, and a fresh `release/3.6` inherits none, so the site keeps publishing from `release/3.5`. The regression risk only materializes when the deploy is *switched* to a `release/3.6` based on today's `main`.
## How the deploy works today
- `.github/workflows/docs-deploy.yml` is present on **`origin/release/3.5`** and absent from **`origin/main`** (the `release/3.4` copy was deleted by #22063). It hardcodes the deploy branch (paraphrased):
```yaml
on:
push:
branches: [release/3.5]
paths: ['docs/site/**']
workflow_dispatch:
concurrency:
group: docs-pages
```
It builds `docs/site` and publishes to the shared `github-pages` environment. There is **no `docusaurus docs:version` step** — snapshotting is never automatic.
- `main` has no *deploy* workflow, but it does carry `docs-site-build.yml` (a `workflow_call` build check: `generate-llms.py --check`, typecheck, `npm run build`). So in-development v3.6 docs on `main` are CI-validated — just never **published**.
- The only automatic version behavior is at build time, and it does **not** archive anything or change the default:
- `docusaurus.config.ts` resolves version strings from the GitHub releases API — **current** docs use `fetchLatestVersion()` → `releases/latest` (the *globally* latest non-prerelease, e.g. `3.5.1`, `v`-stripped); **archived** versions use per-series `fetchLatestSeriesVersion()`.
- The `version-replace.js` remark plugin substitutes `{ERIGON_VERSION}` tokens using those strings.
- ⚠️ **Hazard:** once `v3.6.0` is published, `releases/latest` returns `3.6.0`. Any rebuild/redeploy of the still-live `release/3.5` site (a push touching `docs/site/**`, or a manual `workflow_dispatch`) will then inject `3.6.0` into the v3.5-labelled current docs. Complete the deploy switch promptly after release, or avoid rebuilding `release/3.5` in that window.
## Versioning model
- `docs/site/docs/` on the deploy branch = the **current/default** version (with the current `lastVersion: 'current'` config).
- `docs/site/versions.json` + `docs/site/versioned_docs/version-vX/` + `docs/site/versioned_sidebars/version-vX-sidebars.json` = **frozen archived** versions.
- The current-version label is **hardcoded** in `docusaurus.config.ts` (`versions.current.label`).
Current state:
| Branch | current label | `versions.json` | `versioned_docs/` + `versioned_sidebars/` |
|---|---|---|---|
| `release/3.5` (live) | `v3.5` | `["v3.4","v3.3"]` | v3.4, v3.3 |
| `main` (future 3.6 base) | `v3.4` | `["v3.3"]` | v3.3 only |
## ⚠️ `main` is stale
The v3.5-default / v3.4-archive transition (#22062) was applied to `release/3.5` only and never forward-ported to `main`. If the deploy were switched to a `release/3.6` cut from today's `main`, the site would come back labelled **"v3.4 current"**, would **lose the v3.4 archive**, and would **carry no v3.5 content at all**. (v3.5 was never archived — it is `release/3.5`'s *current*.)
## Work required (mirrors #22062 + #22063)
### A. Fix `main`'s stale versioning (independent of the cut; makes any future cut cleaner)
- [ ] Carry the **v3.4** archive that `main` is missing: `versioned_docs/version-v3.4/`, `versioned_sidebars/version-v3.4-sidebars.json`, and `"v3.4"` in `versions.json`.
- [ ] Bump `versions.current.label` off the stale `v3.4` (→ `v3.6` now; note this label bump recurs every cycle — `main` becomes 3.7-dev after the 3.6 cut).
- [ ] **Do not** pre-create a v3.5 snapshot on `main` — it would go stale as `release/3.5` keeps taking backported doc fixes until the cut. The v3.5 archive is created at transition time from the real `release/3.5` tip (see B).
### B. At the 3.6 transition, on the new deploy branch `release/3.6` (mirror #22062)
- [ ] **Snapshot v3.5 from the real `release/3.5` docs content** (not from `release/3.6`'s current, which is v3.6-dev): produce `versioned_docs/version-v3.5/` + `versioned_sidebars/version-v3.5-sidebars.json` and add `"v3.5"` to `versions.json`. #22062 did exactly this for v3.4 ("sourced from the real `release/3.4` docs content").
- [ ] Set `versions.current.label` to `v3.6`; `docs/site/docs/` = v3.6 content.
- [ ] **Fix archived absolute links** for any pages renamed/moved between v3.5 and v3.6 (and the `@docusaurus/plugin-client-redirects` entries). #22062 had to prefix the v3.4 archive's links for pages renamed in v3.5; `onBrokenLinks: 'throw'` will hard-fail the build otherwise.
- [ ] **Decide v3.3 retention (3-version cap).** #22062 kept "2 archives + current". Freezing v3.5 while keeping v3.4 **and** v3.3 = 3 archives + current, over the cap — decide whether to retire v3.3 (drop from `versions.json`, delete `versioned_docs/version-v3.3/` + its sidebar).
- [ ] Confirm `generate-llms.py --check` passes on the new branch (regenerate only if the v3.6 current content changed — the generator reads `docs/` + `help-center/`, not `versioned_docs/`). The four artifacts are `llms.txt`, `llms-full.txt`, `docs/site/static/llms.txt`, `docs/site/static/llms-full.txt`.
- [ ] Add `docs-deploy.yml` on `release/3.6` with `branches: [release/3.6]`. Note this commit **is the deployment cutover** (it touches `docs/site/**`), so it must already contain the correct archived/default state.
### C. Retire the old deploy (mirror #22063)
- [ ] Delete `docs-deploy.yml` from `release/3.5` — **before, or atomically with**, landing the new workflow on `release/3.6`. #22062's companion #22063 was merged first for exactly this reason: two branches pushing to the shared `github-pages` environment race (the `docs-pages` concurrency group cancels in-progress runs, but the environment is last-writer-wins).
## References
- #22062 — publish v3.5 as default, archive v3.4 (on `release/3.5`; commit d2ca65b072)
- #22063 — retire `release/3.4` docs deploy (on `release/3.4`; deleted the workflow, commit fbb7efd9b8)
Contributor guide
Assessment
This issue has not been assessed yet.