[daniel-kmiecik]

Pull Request

Thank you for contributing to swagger-core!

Please fill out the following information to help us review your PR efficiently.

---

Description

This pull request introduces a comprehensive release automation system for the 1.5 branch (swagger-core v1) using GitHub Actions workflows and supporting scripts. The changes include new CI/CD workflows for preparing and executing releases, supporting Python and shell scripts for release management, and documentation updates. These improvements standardize and automate the release process for the v1 line, ensuring releases are only made from the correct branch and version, and providing clear release notes and artifact deployment.

Release Workflow Automation

• Added new GitHub Actions workflows for preparing and executing releases on the 1.5 branch, including branch and version checks, artifact signing, and automated pull request creation for release and snapshot version bumps (.github/workflows/prepare-release.yml, .github/workflows/release.yml).

Release Management Scripts

• Introduced Python and shell scripts in the CI/ directory to automate steps such as finding the last release, drafting release notes, publishing releases, updating Maven versions, and bumping snapshot versions (CI/lastRelease.py, CI/releaseNotes.py, CI/publishRelease.py, CI/ghApiClient.py, CI/prepare-release.sh, CI/pre-release.sh, CI/post-release.sh).

Documentation

• Added CI/CI.md to document the new release process, workflow steps, differences from other branches, and required secrets for secure publishing.

Build Configuration

• Upgraded the maven-gpg-plugin version in pom.xml from 1.6 to 3.2.8 to support modern GPG signing and integration with the new workflows.

Type of Change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactor (non-breaking change)
• 🧪 Tests
• 📝 Documentation
• 🧹 Chore (build or tooling)

Checklist

• I have added/updated tests as needed
• I have added/updated documentation where applicable
• The PR title is descriptive
• The code builds and passes tests locally
• I have linked related issues (if any)

Screenshots / Additional Context

[Copilot]

🟡 Changes recommended

Unresolved publication and release-consistency issues can leave deployed Maven artifacts without a matching GitHub release.

5 open issues

• Grant release jobs contents write permission · New
• Tag releases at the artifact build commit · New
• Use PATCH for updating GitHub releases · New
• Paginate release lookup and error on missing draft · New
• Paginate closed pull requests before merge-date filtering · New

What changed in this PR

This PR adds release automation for swagger-core’s v1 line on branch 1.5, covering release preparation, artifact deployment, and next-snapshot updates.

Changes:

• Adds manual preparation and release workflows with branch and version checks.
• Introduces scripts for release discovery, release notes, publication, and Maven version updates.
• Documents the release process and upgrades the Maven GPG plugin to 3.2.8.

File	Description
pom.xml	Updates the Maven GPG plugin for artifact signing.
CI/​releaseNotes.py	Generates release notes and creates a draft release.
CI/​publishRelease.py	Finds and publishes the prepared draft.
CI/​prepare-release.sh	Prepares release versions, updates README, and builds.
CI/​pre-release.sh	Calculates versions and builds before deployment.
CI/​post-release.sh	Publishes the release and sets the next snapshot version.
CI/​lastRelease.py	Searches paginated releases for the latest published v1 tag.
CI/​ghApiClient.py	Provides authenticated GitHub API helpers.
CI/​CI.md	Documents workflows, release steps, and required secrets.
.github/​workflows/​release.yml	Automates deployment, publication, and the snapshot PR.
.github/​workflows/​prepare-release.yml	Automates release preparation and its review PR.

_{Review effort: Balanced}

[daniel-kmiecik]

Not applying changes from copilot's comments. The scripts and workflows are a port of the ones already used for releases on master (2.x) and 3.0.0, and they work there:

• contents: write: repo default workflow permissions are already write, and master relies on the same GITHUB_TOKEN.
• POST vs PATCH: master publishes releases through the same postUrl call, so GitHub accepts it.
• target_commitish: same behavior as master; merges to 1.5 need manual approval, so a race during a release is not realistic.
• Pagination (publishRelease.py, releaseNotes.py): the draft is always the newest release, and a v1 release covers well under 100 PRs, so the first page is enough.