| name | release-new-version |
| description | Orchestrates the process of shipping a new software version by chaining four engineering skills into a structured release pipeline. Covers release planning with changelog generation, commit history analysis, deployment execution, and post-release monitoring verification. Use when the user needs to ship a release with proper versioning, documentation, and deployment verification. Do NOT use for hotfixes that bypass the normal release process or for continuous deployment where every merge auto-deploys. |
| license | Apache-2.0 |
| type | workflow |
| skills | release-management conventional-commits deployment-strategies monitoring-alerting |
| trigger_phrases | release new version ship a release cut a release deploy new version version bump |
| metadata | {"author":"foundry-skills","version":"1.0.0","tags":"devops ci-cd planning step-by-step","category":"software-project","depends":"release-management conventional-commits deployment-strategies monitoring-alerting","disclaimer":"none","difficulty":"intermediate","interactivity":"auto"} |
Release New Version
Estimated time: 2-8 hours (depending on release complexity and verification requirements)
This workflow chains four atomic skills into the process of shipping a new software version from preparation through deployment and monitoring verification. It covers version determination, changelog generation, deployment execution, and post-release validation. The workflow ensures every release is documented, verified, and recoverable.
When to Use
- User needs to ship a new version of their software with proper versioning and documentation
- User wants a structured release process that produces traceable artifacts
- User is preparing a release for a library, API, application, or service
- User needs to coordinate version bumps, changelogs, and deployment as a single process
- Do NOT use when: the project uses continuous deployment (every merge deploys automatically), shipping a hotfix that bypasses the normal release cadence (use a simplified hotfix process), or the release is documentation-only with no code changes
Prerequisites
Before starting this workflow, ensure:
- All changes are merged: The features and fixes intended for this release are merged to the release branch (main, develop, or a release branch depending on branching strategy)
- CI is green: All tests pass on the branch being released. Do not release with failing tests.
- Release scope is defined: You know which changes are included in this release and can verify they match the intended scope
- Deployment access is ready: You have credentials and permissions to deploy to staging and production environments
Steps
Step 1: Plan the Release (uses: release-management)
Determine the version number, scope, and release timeline. This step inventories all changes since the last release and determines the appropriate version bump based on the nature of the changes.
- Input: Commit history since last release, previous version number, pending issues or tickets, release schedule
- Output: Release plan with: version number (major, minor, or patch based on changes), release scope (list of features, fixes, and breaking changes), pre-release checklist (blocking items that must be resolved), release timeline (cut date, staging verification period, production deployment window), and rollback criteria (conditions under which the release should be reverted)
- Key focus: Version number follows semantic versioning: breaking changes increment major, new features increment minor, bug fixes increment patch. If any commit since the last release introduces a breaking change, this is a major version bump regardless of how many features or fixes are also included.
