swagger-api / swagger-api/swagger-codegen

v3.0.78 release tag applied to master (2.x) branch instead of 3.0.0 branch

Open
#12,697 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Mustache
Stars
17.8k
Forks
6k
PR merge metrics
No merged PRs in 30d

Description

Issue: v3.0.78 release tag applied to master (2.x) branch instead of 3.0.0 branch

Bug description

The v3.0.78 git tag is applied to a commit on the master branch (the 2.x codebase)
instead of the 3.0.0 branch (the 3.x codebase).

Evidence

The tagged commit is a routine 2.x dependency update on master:

$ git show refs/tags/v3.0.78 --stat
commit 70cf625cbea6d813f24adbfc422eef9ecd23656e
Author: robert-hebel-sb <robert.hebel@smartbear.com>
Date:   Mon Dec 29 17:02:31 2025 +0100

    chore(deps): update vulnerable validator & js-yaml (#12659)

Building the CLI JAR from this tag produces a 2.x artefact:

Main-Class: io.swagger.codegen.SwaggerCodegen   ← 2.x namespace
implementation-version: 2.4.51-SNAPSHOT         ← 2.x version

The correct 3.x namespace would be io.swagger.codegen.v3.SwaggerCodegen.

Meanwhile, the 3.0.0 branch has the 3.0.78 release prepared but untagged:

$ git log origin/3.0.0 --oneline | head -4
30d353d chore: bump snapshot to 3.0.79-SNAPSHOT
7aed624 chore: update microdnf before install
1a779509 chore: prepare release 3.0.78
4c588898 chore: prepare release 3.0.78

Impact

The Homebrew formula for swagger-codegen packages the JAR built from the v3.0.78 tag.
Users who install via Homebrew receive a 2.x binary despite the formula advertising 3.0.78:

$ brew install swagger-codegen
$ swagger-codegen version
2.4.51-SNAPSHOT

Any tooling that relies on git ls-remote --tags to find the latest v3.* release will
also pick up this tag and unknowingly build/use 2.x code.

Suggested fix

Move (or re-create) the v3.0.78 tag to point to the "prepare release 3.0.78" commit
on the 3.0.0 branch (1a779509 or 4c5888986), and notify the Homebrew maintainers
so the formula can be updated.

Contributor guide

Open the contributing guide

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.

Research direction

Inspect refs/tags/v3.0.78 with git show and compare it with the release-preparation commits on origin/3.0.0, especially 1a779509 and 4c588898. Confirm the tag resolves to the 3.x release rather than the 2.x master commit, then notify the Homebrew maintainers so the formula can be updated.

Written by the indexing model from the issue text.

Assessment

Tech stack
git
Domain
release
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.