Fold 0.3rc1 into main; main is the development branch at 0.2.5-DEV - #69
Merged
Merged
Conversation
Version bumps per merge cost the downstream rigs a verification pass each, and they pin exact tags, so a release should be one tag and one migration note. Work for the next release now collects on a branch named like `0.3rc1`, cut from the release it follows; the version moves once, when the release is cut. Two CI changes make that workable: - `Version bumped` now runs only for pull requests into `main`. It demands a plain X.Y.Z strictly greater than the base, so on a branch that deliberately does not bump it would reject every pull request. - A push to a release-candidate branch runs the full matrix, because it is the integration point. Pull requests INTO it still run the reduced set, as any pull request does. `main` stays open for genuine safety hotfixes tagged as patches, with a standing rule to merge `main` forward whenever one lands. Drift is the real cost of a long-lived branch and merging forward promptly is what bounds it. Suite: 959 passed, 8 broken, 0 failed. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
initialize_original ignored PI_FRF's return. When the reference move was rejected (GCS error 5, e.g. one axis's servo off), the later move to (12.5, 12.5) was rejected too, and the driver believed the stage was centred while the controller read about 0 and held error 5. Reported by the MicroscopeAdapt rig. Now initialize checks PI_FRF's return, then polls PI_qFRF (BOOL* = one Cint per axis) until both axes report referenced, with a 60 s timeout. Either failure throws with the PI_GetError code and closes the connection first, so a retried initialize starts clean rather than hitting "already initialized". referencemove's signature and return are unchanged; the two helpers are internal. Untested on hardware. Local suite on Windows / Julia 1.13: 950 pass, 8 broken; the 1 fail + 1 error are the Windows-only skills symlink and path-separator tests, unrelated to this change. Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Lab decision 0033's branch model: main carries the next version with -DEV and every pull request goes into it. v0.2.4 is tagged, so main moves to 0.2.5-DEV, and the 0.3rc1 release-candidate branch, which never released, is merged in here (a real merge, so pull requests cut from it keep a clean diff once retargeted to main) and retired. 0.3rc1 carried two changes: - #64, PI stage: initialize refuses to finish unreferenced. A fix on a path that was already broken, so non-breaking; now in CHANGELOG [Unreleased]. - #63, the release-candidate process. Its CLAUDE.md "Versioning" text is replaced by the -DEV model (backport branches only for safety fixes), and its two CI rules are undone: the full matrix on pushes to rc branches, and the version check limited to pull requests into main. The check runs on every pull request again; versions.py already accepts ordinary -DEV work. TagOnMerge reads 0.2.5-DEV and exits 0 without tagging. Suite: 998 pass, 8 broken, 0 fail, 0 error (kitt, Julia 1.13). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The policy paragraph still said to bump y for every non-breaking change, in 0.x.y, which contradicted the -DEV model above it (ordinary pull requests leave the version alone). Review nit F1 on #69. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kalidke
added a commit
that referenced
this pull request
Sep 29, 2026
Resolved so that 0.2.4's released TCube safety behaviour holds on this branch's API: - light_on keeps this branch's structure (require_clamp, intended_code, send_setpoint_ramped) with 0.2.4's failure handling: if the setpoint fails after the enable, the disable's status is checked, is_on becomes false only if it succeeded and true otherwise, and both failures are logged (review blocker 1). Open loop checks drive_current against the ceiling before the enable, and light_on warns when it sends 0 because nothing was requested. - zero_then_disable (light_off, shutdown) is 0.2.4's: one write of 0 with no status read and no read-back wait, logged if it fails, then the disable (review should-fix 4). Three assertions of this branch's call sequences change accordingly, and "a zero that cannot be confirmed" becomes "a zero that fails". - The fake SDK keeps this branch's controller model; 0.2.4's names (stored, output_on, enable_log, reset!(stored=)) are views of it, so test/tcube_output_order.jl runs unchanged. - Project.toml takes main's 0.2.5-DEV; README and skill pins stay at v0.2.4; rig-causes takes 0.2.4's row for the ignored-setpoint hazard. tcube_output_order.jl errors at this commit: it builds TCubeLaser without `mode` and calls setpower, which the next commits restore (decision 0035). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kalidke
added a commit
that referenced
this pull request
Sep 29, 2026
…s version numbers Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kalidke
added a commit
that referenced
this pull request
Sep 29, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> # Conflicts: # CHANGELOG.md # test/runtests.jl
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
1 participant
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.
Item D of the branch-model migration (lab decision 0033), after v0.2.4.
Merge with "Create a merge commit", not squash. This is a real merge of
0.3rc1. #67 and #66 were cut from0.3rc1and carry its commits; squashing would leave those commits out ofmain's history, so once the two PRs are retargeted their diffs would show #63 and #64 again.Project.toml0.2.4 -> 0.2.5-DEV. TagOnMerge reads a -DEV version and exits 0 without tagging (TagOnMerge.yml:46-48), so this merge is not tagged. It still carries alab/testsrecord, as every merge does (decision 0012).0.3rc1folded in (it never released):initializerefuses to finish unreferenced. This fixes a path that was already broken, so it is non-breaking; it now has an entry in CHANGELOG [Unreleased].main, and a release branch is cut only for a safety backport. Its two CI rules are dropped (the full matrix on rc-branch pushes, and the version check limited to PRs into main), so the version check runs on every PR again;versions.pyaccepts -DEV work.Local suite on the merge: 998 pass, 8 broken, 0 fail, 0 error (kitt, Julia 1.13).
versions.py check-pr 0.2.5-DEV 0.2.4passes.After merge: retarget #67 and #66 to
main, then delete0.3rc1. No public signature or config type changes here (decision 0035).🤖 Generated with Claude Code