Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

fix(release): accept independent core and Pi versions in candidate validation

Closed
  • Is something wrong?
#1,989 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@dnlrsls is already working on this.

Since Oct 21, 2026.

  • #1990 by @dnlrsls — merged

Assessment

This issue has not been assessed yet.

Description

status:approved type:bug
Existing Issue Search
  • I searched existing issues and will add evidence to a canonical tracker when applicable.
📝 Observed Consequence

Release-candidate tooling rejects a core/Pi pair with different version numbers even when the selected Pi manifest and installer pin agree. This prevents validating the independent SemVer pair required by the canonical release policy. Local Pi package validation also inherits the identical-version restriction.

🔄 Steps to Reproduce
  1. At source commit 3f0b44554dbed8fa8edc976cfe7a6c783376ef88, prepare an isolated metadata fixture with plugin/pi/package.json selecting gentle-engram 0.5.0 and internal/setup/setup.go containing the literal installer constant piGentleEngramPackage = "npm:[email protected]".
  2. Run the public helper from that checkout: go run ./tools/release-candidate -root -core-ref refs/tags/v3.0.0 -pi-ref refs/tags/pi-v0.5.0.
  3. Observe the equality rejection before Pi metadata validation. The original public-command regression also reproduces this for core 1.2.3+a with Pi 1.2.3+b.
✅ Expected Behavior

Both full refs independently satisfy strict SemVer and identify an ordered core/Pi pair. Metadata and local archive validation bind to the selected Pi version, not the core version. Malformed refs, mismatched Pi manifests/pins and invalid archives still reject. Metadata/package success must not imply semantic parity, runtime compatibility, release approval or publication permission; the rejection-only checker must retain all schema/semantic blockers.

❌ Actual Behavior

The helper exits 1, emits no stdout and writes exactly "core and Pi versions must match exactly" plus a newline to stderr (go run adds its own "exit status 1" line). The Node rejection-only checker reports "Core and Pi versions must match exactly." instead of reaching semantic blockers. The local package command rejects the independent pair before packing.

Operating System

Windows

Release Version (Report Context)

Source-tooling report at commit 3f0b44554dbed8fa8edc976cfe7a6c783376ef88; not a claim about an installed or published release. Fresh remote main 258e7a3b145879968dde10d1cdbe52bb30d87add still contains the equality rejection and core-bound metadata validation by source inspection. The recorded execution reproduction is against 3f0b4455, not a fresh execution of the newer main.

Agent / Client

Other

📋 Relevant Logs
# Original regression run before production changes:
go test ./tools/release-candidate -run '^TestReleaseCandidateIndependentPair$' -count=1
# exit 1; observed helper diagnostic:
core and Pi versions must match exactly
exit status 1
💡 Additional Context

This is a deliberately bounded child/delivery issue of #1349, created with the user's explicit authorization so a focused PR can close this defect without closing the umbrella coordinator. #1349 remains canonical for the wider release coordination effort; this issue covers only its first remaining tooling/docs item.

Root cause established at the reproduced baseline: the Go helper enforces equal core/Pi versions and passes the core version to Pi metadata/archive validation; the Node package wrapper also uses that single version for the archive filename.

Acceptance scope:

  • Support independent full-ref inputs with unchanged strict SemVer validation.
  • Keep JSON version as core identity and add piVersion to identify the selected Pi companion in metadata and package results.
  • Bind the Pi manifest, installer pin and tarball to Pi; retain existing equal-version behavior and rejection guarantees.
  • Align CLI help and docs/RELEASE-CANDIDATE.md with independent versions and explicit proof limits.

A local, unpublished candidate already exists in commit 0a60295c4fad60dbf9946d9058f0ca3b04c86434. Original RED was observed before implementation. Subsequent focused Go regression, affected Go package, 34 Node checker/package tests, six baseline differential probes and independent technical verification passed. Full Pi suite: 570 passed, 0 failed, 1 skipped packaged/prebuilt-fixture case. Native RDD review of that exact candidate was approved and acknowledged. These are local candidate results, not hosted CI or release readiness proof; the newer main has not been retested with this candidate.

Non-goals: a positive semantic release certificate, publication state/concurrency/recovery coordinator, workflow/publisher/settings changes, actual version or installer-pin changes, tags, registry publication, Homebrew redesign, runtime negotiation (#1350), or automatic latest promotion. Promotion remains manually and separately authorized. No push or PR has been performed. This issue must start as status:needs-review; neither #1349's approval nor the local review automatically approves this separate issue. Maintainer approval and a real assignee remain required before the PR.

Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
8h 48m
Merged PRs (30d)
340

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.