hegeltest 0.2.0-x86_64-linux → 0.2.1-x86_64-linux

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 002b96ea526d4a771046a0cde5d984554bf945d45d2e1f403d99b1662ea4809e
-  data.tar.gz: 7f58cf4828c9cab85010f4e2e3df1ade6ff7c6092e213007a34421687d2135ac
+  metadata.gz: a982eb65094c033fd232751d0d426b34ac87ab21a35b976e5db1f7710e843603
+  data.tar.gz: eb9442fb05a6415f91c71c222475590eef8ae15ae50f00aff830aecd9bba6b45
 SHA512:
-  metadata.gz: b4e9384ac83849a11f404908f046cac1ec6144445e36bd6546900fb7d90763194cd600906f07d944ce5d3cf1d1aa3f30942a8b834fea2f1d1daf741b64f56070
-  data.tar.gz: 6137838f7bfb75a2d5d183aaf02306b99093c37e160c6726823402534123523434f02c658c02a4ea72e102a86eaa198a38868b6caacb2a0e85a7e0e8ff537ece
+  metadata.gz: d4057d297863376fdc6afb7b23236eeb7102683e07a36f69ce937e37db829bd17604f5a25c97fccbe4062818e155f0c1631eab159a7e3524800010144c8c4b0c
+  data.tar.gz: ded73a9f66f6c1693c7403c40f76c35d5b2b59b785d1fbc0e9178ff16c76d9a6a87e0fe2140246cbea5812168d4262657f1ef9d2361777b795c79ecf54833aca

data/CHANGELOG.md

@@ -2,6 +2,14 @@
 
 ## [Unreleased]
 
+## [0.2.1] - 2026-10-08
+
+Each platform gem carries `libhegel` 0.45.1, up from 0.45.0. A caller has
+nothing to change. The engine now reads a NULL string buffer with length
+zero as the empty string, and it rejects a NULL buffer with a nonzero
+length. These bindings send neither case, so a drawn value does not
+change: `from_regex("", fullmatch: true)` draws `""` on both engines.
+
 ## [0.2.0] - 2026-10-07
 
 The floor is Ruby 3.4. A project on Ruby 3.3 stays on 0.1.1. See
@@ -120,6 +128,7 @@ The engine is called through the `ffi` gem. Each platform gem carries the
 matching `libhegel` 0.32.5 build. The platform-independent gem carries none,
 so a run on it needs `HEGEL_LIBHEGEL_PATH` pointing at a local build.
 
+[0.2.1]: https://github.com/meganemura/hegel-ruby/releases/tag/v0.2.1
 [0.2.0]: https://github.com/meganemura/hegel-ruby/releases/tag/v0.2.0
 [0.1.1]: https://github.com/meganemura/hegel-ruby/releases/tag/v0.1.1
 [0.1.0]: https://github.com/meganemura/hegel-ruby/releases/tag/v0.1.0

data/docs/README.md

@@ -30,6 +30,7 @@ An index of the design records for `hegel-ruby`.
 - [0021: Run a state machine in rounds, with its own step count](adr/0021-run-a-state-machine-in-rounds-with-its-own-step-count.md)
 - [0022: Keep microsecond times over a nanosecond engine](adr/0022-keep-microsecond-times-over-a-nanosecond-engine.md)
 - [0023: Leave unset settings to the engine's profile](adr/0023-leave-unset-settings-to-the-engines-profile.md)
+- [0024: Release when a merge changes the gem version](adr/0024-release-when-a-merge-changes-the-gem-version.md)
 
 A new decision gets a new record. A changed decision supersedes the old
 record instead of editing it, so the history stays readable.

data/docs/adr/0024-release-when-a-merge-changes-the-gem-version.md

@@ -0,0 +1,49 @@
+# 0024: Release when a merge changes the gem version
+
+## Status
+
+Accepted. Replaces the tag push that started the Release workflow.
+
+## Context
+
+A release took three steps from the maintainer: merge the pull request that
+prepares the version, push the tag `v<version>` on the merged commit, and
+approve the `release` environment. The tag carried no decision of its own.
+The version in `lib/hegel/version.rb` already said what to release, and the
+approval was the real gate.
+
+A daily routine now opens a pull request for each new libhegel release, with
+a "Prepare <version>" commit. The maintainer's part should be the decision,
+not the steps around it.
+
+GitHub does not start a workflow from a push that a workflow makes with its
+own `GITHUB_TOKEN`. A workflow that pushed the tag after a merge would
+therefore not start a tag-triggered Release workflow.
+
+## Decision
+
+The Release workflow starts on a push to `main` that changes
+`lib/hegel/version.rb`. Its first job reads the version and looks for the tag
+`v<version>`. When the tag exists, as after a revert to a released version,
+the run stops there. Otherwise the publish job waits for the `release`
+environment approval, then builds and pushes the gems from the merged
+commit. The last job creates the tag on that commit and the GitHub release
+together, with `gh release create --target`.
+
+The tag is created last, after the gems are out. A rejected approval then
+leaves no tag behind, and rerunning the workflow run releases the same
+commit later.
+
+Two alternatives were refused. A workflow that only pushed the tag needs a
+personal access token or a GitHub App token to start the tag-triggered
+workflow, which is a long-lived secret for one step. Creating the tag before
+the approval leaves a tag for a version that may never ship, and the check
+job would then skip that version for good.
+
+## Consequences
+
+A release is one merge and one approval. Merge a pull request that changes
+the gem version only when that version should ship.
+
+A tag pushed by hand no longer starts a release. The workflow's own run on
+`main` is the place to retry one.

data/lib/hegel/libhegel_version.rb

@@ -5,5 +5,5 @@ module Hegel
   # Hegel::VERSION (the gem's own release): hegel-go and hegel-typescript keep
   # the two separate too, so bumping the pinned engine can land as its own
   # commit without also releasing a new gem version.
-  LIBHEGEL_VERSION = "0.45.0"
+  LIBHEGEL_VERSION = "0.45.1"
 end

data/lib/hegel/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Hegel
-  VERSION = "0.2.0"
+  VERSION = "0.2.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: hegeltest
 version: !ruby/object:Gem::Version
-  version: 0.2.0
+  version: 0.2.1
 platform: x86_64-linux
 authors:
 - meganemura
@@ -69,6 +69,7 @@ files:
 - docs/adr/0021-run-a-state-machine-in-rounds-with-its-own-step-count.md
 - docs/adr/0022-keep-microsecond-times-over-a-nanosecond-engine.md
 - docs/adr/0023-leave-unset-settings-to-the-engines-profile.md
+- docs/adr/0024-release-when-a-merge-changes-the-gem-version.md
 - docs/architecture.md
 - lib/hegel.rb
 - lib/hegel/draw_name.rb