Publishing is a manual tag push, and the drift is what produced yesterday's 404s
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
未指定檔案、測試或工作流程進入點。先檢查目前 publish* 標籤如何在此儲存庫以及 .fa、.fr 和 .zh-cn 版本中觸發發布，然後比較合併、排程和漂移偵測選項。完成的標準是：形成一項已達成共識的政策和協調一致的行為，將所有版本的過時程度控制在一定範圍內。
由索引模型根據 Issue 內容生成。
描述
The pattern
Every repository in this series publishes only when someone pushes a publish* tag — this repo and the .fa, .fr and .zh-cn editions alike. Merging to main changes nothing a reader can see.
That is a deliberate design and it has real merits: publishing is expensive, and a manual gate means someone decides when the site changes. But the gate is currently the only thing scheduling publication, and in practice it drifts. State as of this morning, before today's round of tags:
| Repository | Last published | Days stale |
|---|---|---|
| lecture-python-programming | 2026-07-16 | 18 |
.fa |
2026-06-19 | 45 |
.fr |
2026-07-17 | 17 |
.zh-cn |
2026-06-19 | 45 |
This repo had three lecture-affecting commits on main that no reader could see.
What that drift actually cost
Three things surfaced yesterday that all trace back to it, and none of which looked like a publishing problem at first:
polars 404'd in every language for four days. Added here on 2026-07-30 in #408, synced to all three translated editions and merged into each within the hour. Content and _toc.yml entries were correct everywhere. It was still 404 on all four sites — including this one — purely because nothing had been tagged since. The first read of that evidence was "the translations have not caught up", which was wrong; the English site did not have it either.
A wrong canonical stayed live for 45 days. The .zh-cn edition was emitting the English URL as its canonical on every page, telling search engines the entire Chinese edition was a duplicate of this one. Fixed in .zh-cn#80, but the fix only reached readers when that edition was finally tagged.
Divergence windows are set by tag timing, not translation speed. Sync PRs across all three editions merge in 8 minutes to 2 days, nearly always within the hour. Publishing lags by weeks. So when the language switcher advertises a page some edition does not have, the gap is almost entirely publish cadence — an inversion of the assumption I first wrote up in QuantEcon/action-translation#239, which had to be rewritten after measuring.
Yesterday's round is the counter-example: all four editions were tagged within about two minutes, all four builds succeeded in roughly six, and the switcher, the canonical fixes and polars all landed everywhere simultaneously. No divergence window opened at all. That is what good looks like, and it happened because someone did four things by hand in one sitting.
Worth considering
Not a concrete proposal — the right answer depends on how much manual control you want to keep:
- Publish on merge to
main, with the tag retained for deliberate re-publishes. Maximum freshness, least control. - Scheduled publish — a weekly or nightly cron that tags if
mainhas moved. Bounds staleness without publishing on every merge. - Keep it manual but make drift visible — a check that opens or comments on an issue when
mainis more than N days or M commits ahead of the last publish tag. Cheapest, and it addresses the actual failure, which is that nobody knew. - Whatever is chosen, coordinate the editions. The translated sites should publish close to this one. Their content is usually ready within the hour; it is the tags that spread them weeks apart.
The last point is the one I would weight most. The individual staleness is survivable; the editions drifting apart is what produces reader-visible breakage now that they cross-link.
Related
- QuantEcon/action-translation#239 — asks for a check that detects switcher and
hreflangtargets returning 404. Largely a symptom of this; worth less if publishing becomes regular. - QuantEcon/quantecon-book-theme#421 — language-aware 404 page, which softens the reader-facing half of the same window.
- 主要語言
- JavaScript
- 星號
- 72
- 分支
- 33
- 平均合併
- 4 天 18 小時
- 30 天內合併 PR
- 3
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
QuantEcon/lecture-python-programming 的其他 Issue
-
難度 1/5 1 小時以內 新手友好度 92/100
QuantEcon/lecture-python-programming#642 ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 90/100
QuantEcon/lecture-python-programming#634 ·
維護者通常 1 天內回覆
-
Prose typos in functions, oop_intro and python_oop (found via French edition review)可能已有人在做 @SwetaKumari7 於 13 天前認領。 未關閉
難度 1/5 1 小時以內 新手友好度 95/100
QuantEcon/lecture-python-programming#633 ·
維護者通常 1 天內回覆
-
難度 1/5 1-3 小時 新手友好度 88/100
QuantEcon/lecture-python-programming#608 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 82/100
QuantEcon/lecture-python-programming#607 · 1 則留言 ·
維護者通常 1 天內回覆
查看 QuantEcon/lecture-python-programming 的全部 Issue
相似的 Issue
-
Code Cleanup Dev Environment
難度 2/5 1-3 小時 新手友好度 78/100
ProjectSidewalk/SidewalkWebpage#5699 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 68/100
zenstackhq/zenstack#2873 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
Jason-Vaughan/TangleClaw#2195 ·
維護者通常 1 天內回覆
-
permissions in review update icon/data
難度 2/5 1-3 小時 新手友好度 69/100
simple-icons/simple-icons#15062 ·
維護者通常 1 天內回覆
-
難度 1/5 1-3 小時 新手友好度 78/100
githubnext/gh-aw-cao#16664 ·
維護者通常 1 天內回覆