Repository navigation
Releases: kettle-dev/kettle-dev
Release list
v3.1.8
3.1.8 - 2026-10-07
- TAG: v3.1.8
- COVERAGE: 91.65% -- 6276/6848 lines in 49 files
- BRANCH COVERAGE: 75.90% -- 2390/3149 branches in 49 files
- 51.77% documented
Added
-
Kettle::Dev::RubyGemsVersions.fetchaccepts asource:keyword so callers can query a RubyGems-compatible private registry such as gem.coop instead of only rubygems.org. The version cache is now namespaced by source host, so a private registry lagging rubygems.org cannot serve stale answers for the other. The default source keeps the historical bare gem-name cache key, so existing caches remain valid. -
Kettle::Dev::RubyGemsVersions.published_version_numbers(gem_name, source:)returns the version numbers a registry serves for a gem, or nil when the registry could not be consulted. Callers must treat nil as "unknown" rather than "unpublished" so an offline run is not blocked; an empty list, by contrast, means the registry was reached and serves no versions. -
[kc] lockfile-registry-specs:
Kettle::Dev::LockfileReset.registry_gem_specs_from_sourcereturns GEM-section specs as{remote:, name:, version:}so a caller can attribute each pinned version to the registry it was resolved from, which is what makes it possible to detect a locally built and installed gem leaking into a lockfile: bundler resolves against the local gem dir, so an ordinarybundle installcan pin a version no registry serves, and the resulting entry is a normal GEM-section line carrying a valid checksum taken from the installed spec, so nothing in the lockfile text distinguishes it and "is this version published?" can only be answered against the remote that section recorded.gem_specs_from_sourceis now a thin wrapper over it and keeps returning[[name, version]]unchanged. -
Kettle::Dev::RubyGemsVersions.published_version_numbersaccepts aversion:keyword and forwards it tofetchas a cache-bust hint, so the on-disk release marker thatkettle-releasewrites after publishing busts the cache for exactly that gem and version instead of for every gem released within the marker TTL. Without it a caller cannot distinguish "published moments ago in this very run" from "released sometime in the last month". Also addsRubyGemsVersions.recently_released?(gem_name, version), which reports whether the marker records that exact gem and version as published within the TTL, treating a missing or corrupt marker as false rather than raising.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.7
3.1.7 - 2026-10-04
- TAG: v3.1.7
- COVERAGE: 91.75% -- 6261/6824 lines in 49 files
- BRANCH COVERAGE: 76.08% -- 2388/3139 branches in 49 files
- 51.34% documented
Added
- kettle-release warns when the current branch is not among the release branches its family declares, naming the declaring config and the declared branches, instead of silently treating it as a feature branch destined for trunk.
Fixed
-
Branch-stack release detection now also reads
release.member_target_branches.<gem>from the family root config, so a member whose templated local.kettle-family.ymlis absent (a fresh branch, or a linked worktree) no longer degrades silently into a trunk pull request and a merge into trunk. -
Branch-stack release detection no longer uses block-level
rescueorArray#filter_map, which are Ruby 2.6+ and 2.7+ constructs; the gem supports Ruby 2.4. YAML loading is isolated insafe_load_kettle_family_configwith a method-level rescue, restoring the explicitbegin/endcontract the surrounding code relies on. -
Preserve the selected Gemfile and lockfile when Bundler restarts during release lockfile reset.
Changed
-
[kc] kettle-jem/prepare: updated 13 project files:
- dependencies (13)
-
[kc] kettle-jem/template: updated 7 project files:
- code and tests (2)
- dependencies (1)
- documentation (1)
- other (2)
- workflows (1)
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.6
3.1.6 - 2026-10-02
- TAG: v3.1.6
- COVERAGE: 91.66% -- 6210/6775 lines in 49 files
- BRANCH COVERAGE: 76.13% -- 2370/3113 branches in 49 files
- 51.34% documented
Fixed
-
Branch-stack releases now dispatch selected GitHub Actions workflows directly on the release branch instead of relying on a possibly conflicted validation PR.
-
Branch-stack release workflow validation now supports the older Psych API bundled with Ruby 2.4.
-
YAML loading now selects the supported Psych API by version, including Ruby 2.5 environments that report misleading keyword parameters.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.5
3.1.5 - 2026-09-28
- TAG: v3.1.5
- COVERAGE: 91.43% -- 6170/6748 lines in 49 files
- BRANCH COVERAGE: 75.89% -- 2348/3094 branches in 49 files
- 51.34% documented
Fixed
- Recheck registry gem availability after release lockfile resolution instead of reusing stale negative probes.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.4
3.1.4 - 2026-09-28
- TAG: v3.1.4
- COVERAGE: 91.89% -- 6197/6744 lines in 49 files
- BRANCH COVERAGE: 76.24% -- 2359/3094 branches in 49 files
- 51.34% documented
Fixed
- Centralize canonical path and component-aware containment checks for Kettle tools.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.3
3.1.3 - 2026-09-27
- TAG: v3.1.3
- COVERAGE: 91.63% -- 6155/6717 lines in 48 files
- BRANCH COVERAGE: 76.05% -- 2347/3086 branches in 48 files
- 51.13% documented
Fixed
- Recognize Windows drive, UNC, and relative paths as local lockfile remotes during release validation.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.2
3.1.2 - 2026-09-27
- TAG: v3.1.2
- COVERAGE: 91.60% -- 6149/6713 lines in 48 files
- BRANCH COVERAGE: 76.10% -- 2347/3084 branches in 48 files
- 51.02% documented
Added
- kettle-jem-template-20260913-001 - Templating now also surfaces a review
entry independency_conflicts.resolvewhen a direct development
dependency doesn't support one or more of this project's declared
engines:and has no template-managed modular home (e.g.sqlite3on
jruby). Review each entry and pick a resolution per the project's own
engine support needs.
Changed
-
[kc] kettle-jem/prepare: updated 15 project files:
- configuration (1)
- dependencies (14)
-
[kc] kettle-jem/template: updated 35 project files:
- code and tests (3)
- dependencies (1)
- other (1)
- workflows (30)
Fixed
-
Handle macOS PTY EOF and canonicalize release-contract paths beneath symlinked temporary roots.
-
Run bundled YARD scripts through Ruby on Windows and accept absolute Windows RUBOCOP_LTS_LOCAL paths.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.1
3.1.1 - 2026-09-14
- TAG: v3.1.1
- COVERAGE: 91.54% -- 6138/6705 lines in 48 files
- BRANCH COVERAGE: 76.08% -- 2344/3081 branches in 48 files
- 51.02% documented
Fixed
- Close release-created branch-stack validation PRs after successful publication instead of leaving obsolete conflicted PRs open.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.1.0
3.1.0 - 2026-09-10
- TAG: v3.1.0
- COVERAGE: 91.86% -- 6141/6685 lines in 48 files
- BRANCH COVERAGE: 76.10% -- 2337/3071 branches in 48 files
- 51.02% documented
Fixed
-
[kc] release-graph-contracts: Honor the serialized release graph for lockfile normalization and child commands, retaining only declared CI-resident monorepo paths.
-
Validate serialized family release graph contracts in release lockfile normalization and child commands instead of reconstructing local-path policy from ambient environment.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?
v3.0.34
3.0.34 - 2026-09-09
- TAG: v3.0.34
- COVERAGE: 91.95% -- 6101/6635 lines in 47 files
- BRANCH COVERAGE: 76.43% -- 2332/3051 branches in 47 files
- 50.23% documented
Fixed
-
Detect and reset release lockfiles whose BUNDLED WITH version lacks a matching Bundler checksum.
-
Declare the intentional version_gem runtime-heads dependency overlap for templating self-tests.
Many paths lead to being a sponsor or a backer of this project. Are you on such a path?