103 lines
4.1 KiB
Markdown
103 lines
4.1 KiB
Markdown
# Release Candidate Process
|
|
|
|
Use explicit release candidates. Each RC should have a written scope, known issues, validation
|
|
matrix, generated artifacts, migration/status notes, and feedback request.
|
|
|
|
|
|
## RC1: API And Architecture Candidate
|
|
|
|
Exit criteria:
|
|
|
|
1. RC1 tag and notes exist;
|
|
2. build/test/spec validation is recorded;
|
|
3. feature table, visible parity table, known gaps, Python binding scope, and WebGPU/WASM scope are
|
|
published or linked;
|
|
4. release examples are documented enough for early testers;
|
|
5. public headers, ownership rules, and lower-layer support labels have been reviewed.
|
|
|
|
Success criteria:
|
|
|
|
1. a small number of serious external testers, roughly 5-10, try the release candidate;
|
|
2. installation feedback arrives from Linux, macOS, and Windows;
|
|
3. at least several release examples run outside the main development machine;
|
|
4. reports distinguish build/install failures, rendering or driver bugs, example issues, API
|
|
feedback, documentation gaps, and platform/GPU details;
|
|
5. public discussion does not confuse Datoviz v0.4 RC1 with VisPy 2.0 or with the final v0.4
|
|
release.
|
|
|
|
|
|
## RC2: Packaged Native-Window Hotfix
|
|
|
|
Exit criteria:
|
|
|
|
1. the macOS packaged Vulkan-loader/GLFW mismatch is fixed;
|
|
2. installed-wheel native windows have automated Linux/Xvfb regression proof, while hosted macOS
|
|
retains offscreen MoltenVK render proof without claiming an interactive desktop session;
|
|
3. the exact canonical macOS wheel has explicit attended Quickstart evidence on the MacBook M3;
|
|
4. all six replacement wheels pass the normal RC artifact and conformance gates;
|
|
5. public guidance discloses the RC1 limitation until RC2 is available;
|
|
6. RC2 notes record physical Linux and Windows as unavailable exclusions, not passes; and
|
|
7. unrelated documentation, gallery, provider, and feature work remains deferred.
|
|
|
|
|
|
## RC3: Documentation, Packaging, And Quality Candidate
|
|
|
|
Exit criteria:
|
|
|
|
1. documentation and gallery structure are mostly final;
|
|
2. generated C reference, captured artifacts, RC feedback triage, attribution, and gallery review
|
|
are complete;
|
|
3. Qt/PyQt hosting has a tested packaged `datoviz_qtbridge` provider, preferably conda-first,
|
|
without adding Qt to the base wheel;
|
|
4. only blocker fixes remain after the planned RC3 deliverables;
|
|
5. packaging, licenses, generated artifacts, release notes, and docs are final candidates;
|
|
6. source archives and wheels build, install, and pass installed smoke tests on supported platforms;
|
|
7. static-analysis, memory/UB, Vulkan validation, long-running loop, docs link, gallery smoke, and
|
|
example smoke results are either clean or recorded as known issues;
|
|
8. checksums/signing policy and required third-party notices are decided.
|
|
|
|
|
|
## Final v0.4.0
|
|
|
|
Exit criteria:
|
|
|
|
1. `v0.4.0` is tagged and published with reproducible artifacts;
|
|
2. documentation and release notes are public;
|
|
3. launch screenshots, short clips, README/website assets, and announcement text are generated from
|
|
current gallery examples;
|
|
4. direct feedback channels are open for early users, especially scientists whose public datasets
|
|
are used in showcase examples;
|
|
5. the active queue resets for v0.4 patch work and v0.5 planning.
|
|
|
|
|
|
## Required RC Notes
|
|
|
|
Every RC note should include:
|
|
|
|
1. exact commit and tag;
|
|
2. feature status table;
|
|
3. known issues;
|
|
4. platform validation matrix;
|
|
5. test/static-analysis summary;
|
|
6. docs/gallery build links;
|
|
7. wheel/source artifacts;
|
|
8. migration/status notes from v0.3 and development snapshots;
|
|
9. feedback request targeted at users and contributors.
|
|
|
|
|
|
## Feedback Triage
|
|
|
|
Each RC should have issue labels or project fields that separate:
|
|
|
|
1. installation and packaging failures;
|
|
2. rendering, driver, and platform-specific bugs;
|
|
3. example and gallery failures;
|
|
4. API and ownership/lifetime feedback;
|
|
5. documentation issues;
|
|
6. final-release blockers.
|
|
|
|
After one to two weeks of RC1 feedback, summarize the findings and decide whether the next RC is a
|
|
blocker fix, a documentation/gallery candidate, or unnecessary before the next planned gate. RC1
|
|
feedback produced a narrow RC2 packaged native-window hotfix, moving its former planned scope to
|
|
RC3.
|