kami
6c92f85d10
Bring the Nexus/Praxis/Hexis integration in line with MAVEN_ECOSYSTEM_ARCHITECTURE.md: - Praxis over HTTP: drop the in-process praxis.db open (praxisstore/ praxistools) and call praxisd's /api/v1/tools/* API via a new praxisClient. Honors the "no component reads another's DB" invariant (AC#12). PraxisConfig.DBPath -> URL. - Hexis confirmation gate: mutating capabilities (ReadOnly=false) now park a bound pendingHexis confirmation and require a spoken "да" before executing; read-only run immediately (AC#7, no auto attention->action). - Capability safety: >1 verb match is ambiguous -> ask instead of firing the first; ambiguous Nexus resolution asks for clarification (AC#2). - Correlation IDs on Hexis execute, recorded in the cross-service trace. - Bug: importance arrives as JSON float64 over HTTP, not int. - Tests: confirm-gate, decline, read-only, and ambiguity paths. Build: vendor/ bakes in the hexis client (replace-directed at a sibling repo outside the Docker context); Dockerfile builds from vendor and no longer `go mod download`s the unreachable replace paths. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
66 lines
2.7 KiB
Markdown
66 lines
2.7 KiB
Markdown
## Tagging and releases
|
|
|
|
Please do not tag commits unless all builders at
|
|
https://modern-c.appspot.com/-/builder/?importpath=modernc.org%2fsqlite are
|
|
happy.
|
|
|
|
Unlike most modernc.org repositories, this one is deliberately NOT
|
|
auto-tagged: builder.json sets "autotag": "<none>". Many projects depend on
|
|
modernc.org/sqlite, so letting the build bots tag it automatically is too
|
|
risky. Releases here are tagged manually by the maintainer, once all the
|
|
builders above are green.
|
|
|
|
## CHANGELOG
|
|
|
|
Because releases are tagged manually (see above), the top of CHANGELOG.md can
|
|
run ahead of the actual git tags: a version section may be written and dated
|
|
when the work lands on master while the tag itself is pushed later. Before
|
|
assuming a version is released, check the real latest tag with
|
|
|
|
git ls-remote --tags origin
|
|
|
|
Keep all not-yet-tagged work in a SINGLE pending section at the top of
|
|
CHANGELOG.md. Do not open a new "vX.Y.Z" header per merge request - that splits
|
|
one pending release across several version numbers. Add each merge request's
|
|
entry to the existing pending section, grouped with related work, and let the
|
|
maintainer set the final version number and date when the release is actually
|
|
tagged. The next version is the one after the latest tag reported by the
|
|
command above, not after whatever header currently sits at the top of the file.
|
|
|
|
## Integrating merge requests
|
|
|
|
The canonical repository is GitLab cznic/sqlite; the GitHub mirror does not
|
|
auto-sync merge requests, and the "merge request !NNN" references in
|
|
CHANGELOG.md are GitLab MR numbers.
|
|
|
|
Land a contributor MR by fetching its head ref and merging it with a merge
|
|
commit:
|
|
|
|
git fetch origin refs/merge-requests/<iid>/head
|
|
git merge --no-ff FETCH_HEAD
|
|
|
|
GitLab publishes every MR's commits at refs/merge-requests/<iid>/head
|
|
regardless of which fork the source branch lives on. Merging --no-ff keeps the
|
|
contributor's original commit SHAs and author metadata, and because the MR's
|
|
head commit becomes reachable from master, GitLab automatically flips the MR to
|
|
"Merged" once master is pushed.
|
|
|
|
Do NOT land an MR by downloading its .patch and running git am: that rewrites
|
|
the committer and the commit date, producing a new SHA that GitLab cannot match
|
|
against the MR's source branch. The MR then has to be closed by hand and shows
|
|
as "Closed" rather than "Merged", which reads as "rejected" to anyone scanning
|
|
the list.
|
|
|
|
Match the merge-commit message GitLab itself uses:
|
|
|
|
Merge branch '<source-branch>' into 'master'
|
|
|
|
<substantive subject> (#<issue>)
|
|
|
|
[Closes #<issue>]
|
|
See merge request cznic/sqlite!<NNN>
|
|
|
|
Include the "Closes #<issue>" line only when the MR actually closes an issue;
|
|
omit it for follow-ups. <source-branch> is the contributor's branch name on
|
|
their fork.
|