swagger-api / swagger-api/swagger-codegen
v3.0.78 release tag applied to master (2.x) branch instead of 3.0.0 branch
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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