Release management¶
Use this guide to choose a reproducible revision and record its adoption status. The repository contains the core lab sequence (1–7) and optional Labs 8–15.
History cleanup: 2026-09-25¶
Two historical literal credentials were removed from published branches and tags. The current course file tree was unchanged by the rewrite. Pre-cleanup commit IDs and workflow records below are historical evidence, not fresh checkout targets.
The cleaned baseline is c768edb67279b8d370132ceb567c0d2a5ca0b141, validated by
workflow 36178628941
on Ubuntu 22.04 and 24.04. The next candidate is teaching-2026-09-rc2.
Replace old clones with fresh clones, preserving private work separately. Never
merge or push old history. RC1 was rewritten from 9a75f787e0153577aeefb20e116f226fc350cbe8 to
4997bd928a851dd6961291bfac4b64fdb4527f0b, preserving its course content.
Its reachable history was included in the clean-mirror and fresh-clone scans; RC2 supersedes it for new rehearsals. Rewriting refs
does not erase outside copies or GitHub cached/PR objects. Credential revocation
and server-side removal remain separate checks.
Validated revisions and adoption status¶
| Status | Revision and evidence | Meaning |
|---|---|---|
| Historical reproducibility baseline | 71653bf77f881a62cda029f5ebc344e6702adb4a; September 18 workflow |
Earlier layout; retain as historical evidence, not the starting point for the migrated guides |
| Previous CI-validated migration | da05a646d3f627e65150c523cf944149f2f19d19; successful Ubuntu matrix |
Migrated folders/model; fresh installation and full workflow passed on Ubuntu 22.04 and 24.04 |
| Historical pre-cleanup CI baseline | 2fb0ccb7e92499584d5bfe2fba241699d1a3c29f; successful Ubuntu matrix |
Includes capstone consistency corrections and automated heading-anchor validation; Ubuntu 22.04 and 24.04 passed |
| Human-pilot-tested teaching release | Not yet established | Requires recorded novice and replacement-instructor pilots, a selected revision and a release tag |
The named baseline is a reproducible technical baseline, not a claim of human usability validation. Later commits need their own validation record; success at one revision does not automatically validate subsequent edits.
Frozen release candidate¶
Use the release-candidate record
for the final correction set. Publish teaching-2026-09-rc2 only after the exact
selected commit passes the Ubuntu 22.04/24.04 workflow. Its release notes must
record the full commit SHA, successful workflow URL and pending human pilots.
Until that record is published, use the cleaned baseline
c768edb67279b8d370132ceb567c0d2a5ca0b141 from the history-cleanup section.
After publication, use a fresh rehearsal clone and run:
git fetch origin tag teaching-2026-09-rc2
git checkout --detach teaching-2026-09-rc2
Keep this tag fixed. Later corrections require a new candidate and their own validation. Store final SHA and workflow evidence in the release record rather than editing source files merely to point at each new documentation commit. A release candidate supports technical rehearsal; it is not a human-pilot-tested teaching release.
Framework maintenance¶
Lab 7 uses NIST AI RMF 1.0 as the course's selected reference version. As checked on 2026-09-24, NIST reports that the framework is being revised. Before each offering, check that source, record the selected version in release notes, and review prompts and rubric references together if changing versions. A successor's publication does not silently change an existing course assignment.
Release record¶
Record the selected tag and full commit SHA, passing Ubuntu workflow URL, tested Python/dbt/PostgreSQL versions, validated activities, known limits, and separate novice and replacement-instructor pilot statuses. Use the historical validation below as evidence for its named revision only. Do not describe a new revision as recommended or pilot-tested until its own gates are complete.
The lab directories follow the student sequence under labs/core (1–7) and
labs/optional (8–15). The detailed reporting model is order_detail_mart.
When updating an existing instructor checkout, use current guide paths and
regenerate dbt documentation with Lab 4. Previously generated local documentation
belongs to its earlier revision; do not use it as evidence for the updated model.
Included changes¶
- Optional server CSV audit investigation with positive/negative query evidence.
- Optional transfer across two independent local PostgreSQL instances, actual source shutdown, preserved target, recovery timing and safe retry.
- Optional verified TLS, wrong-trust/hostname/plaintext rejection and credential rotation.
- Optional primary-source governance case with control mapping and stewardship memo.
- Explicit student/core and instructor/rehearsal routes, private configuration and recovery.
Verification and publication¶
The recorded baseline above passed the complete Ubuntu 22.04/24.04 workflow, including student-test discovery and isolated infrastructure experiments. See validation for its scope.
For a versioned release, select the intended commit, confirm its workflow result, record learner/instructor pilot status and historical credential-review status, then publish a tag and release notes. Clearly identify any adoption work without recorded completion. Optional activities do not by themselves establish that all students met every practical outcome in an adopting institution's syllabus.
Updating an instructor rehearsal checkout¶
Fresh student clones use the ignored dbt/it4065c_platform/student_tests directory.
For an existing rehearsal checkout, preserve any learner-created
lab3_guided_daily_orders.sql and lab3_my_sales_rule.sql files before switching
revisions. Move those two files from tests to student_tests after updating;
keep only one copy of each test name inside dbt's configured test paths. Do not
move the supplied repository tests. Rerun Lab 3 and its named-results checker.
Do not force-add ignored student work to Git.
Limits to retain in release notes¶
Batch transfer is not automatic failover or streaming replication. Same-host instances share a failure domain. Student-owned server logs are not independently protected audit records. TLS protects transport, not files/backups. Password rotation does not terminate established sessions. The governance activity is educational analysis. Keep these boundaries visible when other instructors adapt the course.
Pin a tested baseline before adoption¶
For a new instructor rehearsal, the cleaned CI-validated baseline can be selected with:
git checkout --detach c768edb67279b8d370132ceb567c0d2a5ca0b141
Run this only in a fresh rehearsal clone, not a checkout with unsaved work. This selects the exact tested history-cleanup baseline. If adopting later corrections, select their exact commit after verifying that commit's workflow instead. Record the chosen revision and use its matching guides for the entire rehearsal.
Complete and record both human pilots before describing a version as a pilot-tested teaching release. Record automated/assistant-led execution separately from a human instructor walkthrough; neither establishes independent novice or replacement- instructor readiness. The maintainer chooses the tag and adoption date.
Author: Isaac K. Nti.