PLAN: add release gating as P0, correct the consumers table - #137
Merged
Merged
Conversation
Three corrections and one addition. Consumers in production listed three repos and stated every consumer tracks the floating @v0 with no exact pins left. Six exactly-pinned call sites exist across five lecture repos, two to three releases behind -- lecture-jax (x2), lecture-python-intro, lecture-python-advanced.myst, lecture-python-programming and continuous_time_mcs. The omission is not just bookkeeping: the argument in that section was reasoned partly from the incomplete table, and every remaining pin sits on publish-gh-pages, which is the least-gated action. The claim that the canary 'meets a bad release first' held for one consumer path, not three. The weekly cache build does lead consumers by 23-24 hours (Sunday 03:00 UTC against Monday 02:00/03:00). ci.yml fires only on a pull_request in the canary and publish.yml only on a tag push there, so preview and publish have no lead at all -- and publish is the path that reaches readers. More fundamentally the canary pins @v0, the tag a release moves, so it can only ever exercise a published release, never a candidate. Release gating therefore enters the backlog at P0, as items 0a-0d: the gate fixture (#136), the v0-next staging tag (#135), closing the ungated paths regardless, and proving the gate can both stop a release and reach a human. Rollout status row 1 also said preview-netlify@v0.8.0 where python.myst has been on @v0 since the repin, and the table gave no hint that publish-gh-pages is separately at 7/7. Audit: QuantEcon/workspace-lectures#31 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both v0 and v0.11.1 resolve to a388639 -- verified with git rev-list rather than the refs API, which returns the annotated tag object's SHA for release tags and the commit SHA for lightweight ones, making the two look divergent when they are not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 11, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
Updates PLAN.md to reflect an audit of quantecon/actions adoption across lecture repos, correcting rollout/consumer tracking and elevating release gating work to P0.
Changes:
- Corrects the “Consumers in production” section by adding the missing exactly-pinned consumers and clarifying the implications for adoption/gating.
- Adds a new P0 “Release gating” backlog section (items 0a–0d) tied to #135/#136.
- Fixes minor staleness in “Current state” and “Rollout status” (latest release/version notes and rollout table annotations).
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Two corrections from Copilot on #137. The canary's ci.yml was described as firing only on a pull_request. It also has workflow_dispatch. The conclusion is unchanged -- a manual trigger is not a lead -- but the stated reason was wrong, and the accurate framing is stronger: neither preview nor publish has a *schedule*, so neither has any automatic lead over consumers, and a gate cannot rest on someone remembering to dispatch. The neighbouring claims are unaffected: publish.yml really is push/tags 'publish*' only, with no workflow_dispatch, so it cannot be run by hand at all. The rollout table called row 4 lecture-python-programming.myst. The repo is lecture-python-programming -- no suffix -- which the consumers table two sections above already had right. Pre-existing, but inside a row this branch rewrote. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mmcky
added a commit
that referenced
this pull request
Aug 11, 2026
#137 corrected the consumers table and added release gating; this clears what it did not touch, found while triaging all 20 open issues: - backlog item 5 (#14, the Cloudflare alias URL) was still listed as open although #131 shipped it in v0.11.1; its disposition row still read "Still valid" - the dependency policy still pinned the baseline to anaconda=2025.12, a month after #95 migrated both images to 2026.06 - rollout Phase 1 still put lecture-dp on @v0.8.0, contradicting the consumers table above it The disposition table covered 8 issues while 23 are open, so it had stopped working as a status view. Adds a second table for everything opened after the July review. Item 3's "=2025.12" is left alone: it narrates the misconception that produced #86/#87, not the current baseline. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mmcky
added a commit
that referenced
this pull request
Aug 11, 2026
…ker (#139) #137 corrected the consumers table and added release gating; this clears what it did not touch, found while triaging all 20 open issues: - backlog item 5 (#14, the Cloudflare alias URL) was still listed as open although #131 shipped it in v0.11.1; its disposition row still read "Still valid" - the dependency policy still pinned the baseline to anaconda=2025.12, a month after #95 migrated both images to 2026.06 - rollout Phase 1 still put lecture-dp on @v0.8.0, contradicting the consumers table above it The disposition table covered 8 issues while 23 are open, so it had stopped working as a status view. Adds a second table for everything opened after the July review. Item 3's "=2025.12" is left alone: it narrates the misconception that produced #86/#87, not the current baseline. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three corrections and one addition to
PLAN.md, from an audit ofquantecon/actionsadoption across the Python lecture family (QuantEcon/workspace-lectures#31).The consumers table was incomplete, and the error was load-bearing
Consumers in production listed three repos and stated every consumer now tracks the floating
@v0— 11 call sites, no exact pins left. In fact six exactly-pinned call sites exist across five lecture repos, two to three releases behind:lecture-jax@v0.8.0—preview-netlifyandpublish-gh-pageslecture-python-intro@v0.8.0—publish-gh-pageslecture-python-advanced.myst@v0.8.0—publish-gh-pageslecture-python-programming@v0.9.0—publish-gh-pagescontinuous_time_mcs@v0.9.0—publish-gh-pagesThis is not just bookkeeping. The section's argument was reasoned partly from that table, and the omission hides two facts that change it:
publish-gh-pagesis at 7/7 adoption across the publishing lecture repos, and it is also the action every remaining pin sits on — the least-gated action in the set.The case against exact pins is untouched and still stands on its own evidence (
lecture-dpstranded three releases behind with two months of broken alerting; the Dependabot PR that sat 13 days).The canary does not "meet a bad release first"
That claim held for one consumer path, not three:
schedule, Sun 03:00 UTCpull_requestin the canaryPublish is the path that reaches readers. And more fundamentally: the canary pins
@v0, the tag a release moves, so it only ever exercises a published release and cannot test a candidate at all.Release gating enters the backlog at P0
Items 0a–0d: the gate fixture (#136), the
v0-nextstaging tag (#135), closing the ungated paths regardless of the gate, and proving the gate can both stop a release and reach a human. P0 for the same reason the alerting item was — the safety net does not do what it is assumed to do.It also blocks the lecture family's move to floating
@v0, which is otherwise ready (QuantEcon/workspace-lectures#33).Smaller staleness fixed in passing
v0.11.0; it isv0.11.1. Both it and@v0resolve toa388639— verified withgit rev-list, not the refs API, which returns the annotated tag object's SHA for release tags and the commit SHA for lightweight ones and so makes the two look divergent when they are not.preview-netlify@v0.8.0forlecture-python.myst, which has been on@v0since the repin. The table also gave no hint thatpublish-gh-pagesis separately at 7/7, since it tracks the full chain only.lecture-jaxis the suggested full-chain pilot — smallest of the native five and not blocked by build-lectures:-n(nitpick) absent from default strictness; no extra-args passthrough via build-jupyter-cache #97/build-lectures: no_build/.doctreesclear (ipywidget mimetype rendering) #98, which bite intro and programming specifically (Migrate the five native lecture CI pipelines to quantecon/actions/build-lectures meta#348).Docs only; no action code touched.
🤖 Generated with Claude Code