fix(release): gitea_release_plan ignores current_version's tag and includes already-released commits #28

New issue

Closed

opened 2026-10-24 00:59:02 +00:00 by dsh · 1 comment

dsh commented

2026-10-24 00:59:02 +00:00

Owner

Symptom

gitea_release_plan with current_version: "0.7.40-dsh.7" proposes a major bump to v1.0.0 and includes commits that are already released on that tag, e.g. the package rename shipped in 0.7.40-dsh.4. The next intended release is 0.8.

Repro

gitea_release_plan {owner:"dsh-plugins", repo:"dsh-gitea", current_version:"0.7.40-dsh.7"}
→ Release Plan: v1.0.0 (major bump from v0.7.40-dsh.7)
  Changes: 50 across 5 section(s).

  ### 💥 Breaking Changes
  - rename the package to dsh-gitea and drop the runtime dependency by @dsh
  ...

Tags including v0.7.40-dsh.7 exist (gitea_tags list), and git log v0.7.40-dsh.7..master is much smaller than the 50 commits reported.

Observed vs expected

Observed: the plan always starts from the last 50 commits of HEAD; current_version only feeds the bump arithmetic. Released commits contaminate the changelog and force a false major bump.
Expected: with no from_tag, start at v<current_version> (or require from_tag and say so). Plan should read the commits after the current release and propose a minor bump for the current work.

Root cause

lib/release-generator.js (buildReleasePlan):

} else if (client && client.listCommits) {
  const comRes = await client.listCommits(owner, repo, { limit: 50 })

currentVersion is never used to derive a range; fromTag/toTag are only honoured when both are provided.

Proposed fix

When current_version is supplied and from_tag is not, resolve v<current_version> and compare fromTag...HEAD (or to to_tag); fail clearly if the tag cannot be resolved. Keep the existing explicit-range behaviour. Add a test with a fake client asserting the derived range and the resulting bump.

Acceptance: the live call above proposes 0.8.x (minor) and lists only post-v0.7.40-dsh.7 commits; a missing tag produces a clear error.

Duplicate check

Searched release (state all) — #12 covered publishing, no release-plan issue exists.

Layer

dsh-gitea plugin/tool.

## Symptom `gitea_release_plan` with `current_version: "0.7.40-dsh.7"` proposes a **major** bump to `v1.0.0` and includes commits that are already released on that tag, e.g. the package rename shipped in `0.7.40-dsh.4`. The next intended release is 0.8. ## Repro ``` gitea_release_plan {owner:"dsh-plugins", repo:"dsh-gitea", current_version:"0.7.40-dsh.7"} → Release Plan: v1.0.0 (major bump from v0.7.40-dsh.7) Changes: 50 across 5 section(s). ### 💥 Breaking Changes - rename the package to dsh-gitea and drop the runtime dependency by @dsh ... ``` Tags including `v0.7.40-dsh.7` exist (`gitea_tags list`), and `git log v0.7.40-dsh.7..master` is much smaller than the 50 commits reported. ## Observed vs expected - Observed: the plan always starts from the last 50 commits of HEAD; `current_version` only feeds the bump arithmetic. Released commits contaminate the changelog and force a false major bump. - Expected: with no `from_tag`, start at `v<current_version>` (or require `from_tag` and say so). Plan should read the commits after the current release and propose a minor bump for the current work. ## Root cause `lib/release-generator.js` (`buildReleasePlan`): ```js } else if (client && client.listCommits) { const comRes = await client.listCommits(owner, repo, { limit: 50 }) ``` `currentVersion` is never used to derive a range; `fromTag`/`toTag` are only honoured when both are provided. ## Proposed fix When `current_version` is supplied and `from_tag` is not, resolve `v<current_version>` and compare `fromTag...HEAD` (or to `to_tag`); fail clearly if the tag cannot be resolved. Keep the existing explicit-range behaviour. Add a test with a fake client asserting the derived range and the resulting bump. Acceptance: the live call above proposes `0.8.x` (minor) and lists only post-`v0.7.40-dsh.7` commits; a missing tag produces a clear error. ## Duplicate check Searched `release` (state all) — #12 covered publishing, no release-plan issue exists. ## Layer dsh-gitea plugin/tool.

dsh added the

area/forgejo

priority/next

type/bug

labels

2026-10-24 00:59:02 +00:00

dsh referenced this issue from a commit

2026-10-24 01:27:59 +00:00

fix(qa): derive release ranges, render assistant payloads and find packages (#28, #31, #36)

dsh referenced this issue from a pull request that will close it,

2026-10-24 01:28:02 +00:00

fix(qa): derive release ranges, render assistant payloads and find packages #43

dsh closed this issue

2026-10-24 01:28:08 +00:00

dsh commented

2026-10-24 01:28:19 +00:00

Author

Owner

Fixed in b74ca23 (PR #43).

gitea_release_plan now derives the range v<current_version>...<repo-default-branch> when from_tag is absent, honours explicit from_tag/to_tag, and returns a clear error when the tag cannot be resolved instead of silently replaying the last 50 commits.

Live: current_version:"0.7.40-dsh.7" → Release Plan: v0.8.0 (minor bump from v0.7.40-dsh.7), 13 post-tag commits, no already-released package-rename commit.

Tests: test/release-package.test.mjs.

Fixed in `b74ca23` (PR #43). `gitea_release_plan` now derives the range `v<current_version>...<repo-default-branch>` when `from_tag` is absent, honours explicit `from_tag`/`to_tag`, and returns a clear error when the tag cannot be resolved instead of silently replaying the last 50 commits. Live: `current_version:"0.7.40-dsh.7"` → `Release Plan: v0.8.0 (minor bump from v0.7.40-dsh.7)`, 13 post-tag commits, no already-released package-rename commit. Tests: `test/release-package.test.mjs`.