Open the 0.1 release cycle at 0.1.0-rc1 - #398
Conversation
The ABI namespace becomes v0_1_rc1, and the dated CHANGELOG entries collapse into the release entry, which cites its parent 41ac614 as the last commit carrying the full design history — one commit, so the citation is exact. Assisted-by: Claude:claude-fable-5
Assisted-by: Claude:claude-fable-5
A z upgrade never breaks a consumer; the pinned-revision advice and the "unstable until standardization" paragraph predate the tag. Assisted-by: Claude:claude-fable-5
Assisted-by: Claude:claude-fable-5
Assisted-by: Claude:claude-fable-5
Assisted-by: Claude:claude-fable-5
🤖 Augment PR SummarySummary: Prepares the first 0.1 release candidate by bumping the project version to Changes:
🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| Design history of libfn, newest first. The living documents — [README.md](README.md), [CONTRIBUTING.md](CONTRIBUTING.md), [docs/](docs/) — describe only the present state of the design; when a decision makes an earlier idea obsolete, this file is where the transition is recorded and explained. | ||
|
|
||
| ## The conjunction sums two ungraded errors — 25 July 2026 | ||
| ## libfn 0.1.0: the first tagged release — 2 August 2026 |
There was a problem hiding this comment.
CHANGELOG.md:5: Since this PR bumps the repo’s version to 0.1.0-rc1, is it intentional that the top entry is titled “libfn 0.1.0: the first tagged release” (and describes the 0.1.0 tag as already existing)? This may be a bit confusing when reading the changelog at the 0.1.0-rc1 tag.
Severity: low
Other Locations
CHANGELOG.md:7
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| - a bump in **`y`** is a **breaking** change (API and/or ABI); | ||
| - a bump in **`z`** is a bug fix or a purely additive extension: the API and ABI stay compatible, but inline function definitions may change — see below. | ||
| - a bump in **`z`** is a bug fix or a purely additive extension: upgrading never breaks a consumer. | ||
|
|
There was a problem hiding this comment.
README.md:175: The new wording “a bump in z … upgrading never breaks a consumer” seems stronger than “bug fix”, since bugfixes can change observable behavior (and might break consumers depending on prior behavior). Would it help to clarify whether “never breaks” is meant strictly in the API/ABI sense (for a single-version rebuild) rather than behavioral compatibility?
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Assisted-by: Claude:claude-fable-5
Assisted-by: Claude:claude-fable-5
The artifact serves online compilers and standalone reproducers; the workflow verifies it — sentinel plus the polygon example, built and run against a shim include tree — and attaches it to published releases. Examples spell fn includes <>-style for consistency. Assisted-by: Claude:claude-fable-5
Pages serves with the permissive CORS that Compiler Explorer's browser-side URL include needs and GitHub release assets lack, so the exported site carries libfn.hpp. Docs deploy from the release branch only, keeping the site — artifact included — on released, verified content, and the staged footer names the version it was generated from. Assisted-by: Claude:claude-fable-5
|
Assisted-by: Claude:claude-fable-5
Assisted-by: Claude:claude-fable-5
1 participant
Six commits preparing the first release candidate.
Bump the version to 0.1.0-rc1 and summarize CHANGELOG.
VERSIONmoves to0.1.0-rc1; the ABI namespace becomesv0_1_rc1/v0_1_rc1_cxx26, and the sync propagates toports/libfn/vcpkg.jsonandMODULE.bazel. CHANGELOG's dated design-history entries collapse into the release entry — presenting what the library offers at0.1.0rather than a delta from an unreleased past — and the entry cites commit 41ac614, where the full history stays readable. The bump and the rewrite share one commit so that citation is literally the commit's parent.Record how CHANGELOG is summarized for a release. The rule joins CONTRIBUTING
## Versioning: the accumulated entries collapse into a compact, dateless summary immediately before a release, and the summary names the commit carrying the last complete detailed list.Strengthen the z promise and speak to tagged consumers. README's versioning contract now reads "upgrading never breaks a consumer" for
z; the pinned-git-revision advice and the "unstable until standardization" paragraph — both written before any tag existed — give way to tagged-release consumption and the paper-tracking compatibility statement: a facility proposed ininclude/fntracks its paper, and such a change bumpsy, arriving only with a deliberate upgrade.Follow-ups from documentation review. - both in README and TYPE_ALGEBRA
Verification
Full rebuild under the new namespace: 279 targets, 44/44 tests pass. Docs staging runs clean over the modified tree, and pre-commit — including the version-sync, namespace-wrap and README fence-sync hooks — passed on every commit.
After merge
Tag
0.1.0-rc1and cut the release branch. The namespace consequence is intended:v0_1_rc1and the finalv0_1mangle differently, so an rc and the release never link as one.Assisted-by: Claude:claude-fable-5