ci: dispatchable Release workflow + v1.0.0 release notes - #2
Merged
Conversation
…d roadmap Delete the build-process ledger and internal planning docs (PROGRESS.md, SRS, implementation plan, agent prompt) — development history, not useful to library users. In their place: - docs/API.md: consolidated C ABI reference (all functions, error codes, lifecycle/sizing rules, zero-copy borrow rules, segment layout and flags contract, liveness caveat, Python/Rust binding patterns) — closes the long-standing NFR-M2 documentation gap. - docs/ROADMAP.md: triaged upgrade directions (already-shipped vs v1.x candidates vs exploratory). Makefile/ci.yml comments that pointed at PROGRESS.md now carry the explanation inline. .gitignore gains defensive entries for common editor/toolchain droppings. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JykzcEronyifSN4RnTgjTk
… ABI v1.1) New create-time flag SHUTTLE_CREATE_HUGEPAGES advises the segment mapping with madvise(MADV_HUGEPAGE) on Linux — purely advisory (effective only where the kernel THP shmem policy permits), a no-op on macOS, never a correctness dependency. The flag is persisted in the header's cold identity block before the init_state release-store, so openers advise their own independent mapping too; unknown create-flag bits are masked and never persisted. The frozen v1 surface is untouched: shuttle_create keeps its exact signature and is now the create_flags=0 case of the additive v1.1 entry point shuttle_create_ex (SHUTTLE_ABI_VERSION stays 1). The C flag value is static_asserted against the C++ kFlagHugePages bit. The madvise call lives behind the platform seam in platform.hpp, the only file allowed to ifdef on platform. New test shuttle_hugepage_test (suite now 29): flag persisted and observed by a spawned opener, byte-exact transfer on a flagged channel, plain create leaves the bit clear, unknown bits masked. Asserts the flag contract only — never THP outcomes, which are kernel-policy-dependent and would flake in CI. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JykzcEronyifSN4RnTgjTk
…w docs Lead the quick start with the native Linux CMake path (the production target — CI proves it on ubuntu-24.04), keeping the mac+Docker two-platform harness as the secondary block. New 'Using Shuttle in your project' section: add_subdirectory/FetchContent consumption of shuttle_c (C ABI) or shuttle_core (C++), verified by building a real consumer against the published snippet; vendoring guidance for non-CMake builds; pointer to shuttle_create_ex huge-page opt-in. Verification and Scope sections now stand alone (no links to the deleted dev-process docs); test count updated to 29; repository layout reflects docs/API.md + docs/ROADMAP.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JykzcEronyifSN4RnTgjTk
Tag pushes matching v* create a release whose notes come from the annotated tag message (--notes-from-tag), so release notes are curated at tag time and versioned in git. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JykzcEronyifSN4RnTgjTk
Add a workflow_dispatch trigger to the Release workflow: it creates the tag at the dispatched ref and publishes the release, taking notes from .github/releases/<tag>.md when present. Needed because this environment can push branches but not tags; the tag-push path remains for local tagging. Ship the v1.0.0 notes file. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JykzcEronyifSN4RnTgjTk
allandng
marked this pull request as ready for review
July 24, 2026 06:23
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
2 participants
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.
Follow-up to #1, in service of publishing the v1.0.0 release.
What's in this PR
.github/workflows/release.yml: adds aworkflow_dispatchtrigger alongside the existing tag-push trigger. When dispatched with ataginput, the workflow creates that tag at the dispatched ref and publishes the GitHub release, taking notes from.github/releases/<tag>.mdwhen the file exists (falling back to GitHub's generated notes). This path is needed because this environment's git access can push branches but not tags (tag pushes are rejected by the proxy); the tag-push path remains for local/manual tagging..github/releases/v1.0.0.md: curated release notes for v1.0.0 — highlights, verification summary, the benchmark-honesty caveat, and scope.Once merged, dispatching
Releasewithtag=v1.0.0publishes the release from main.Verification
ci.ymlconventions (ubuntu-24.04, minimal permissions:contents: writeonly, which release creation requires).🤖 Generated with Claude Code
https://claude.ai/code/session_01JykzcEronyifSN4RnTgjTk
Generated by Claude Code