@mridang/semantic-release-peer-version v1.1.1
Semantic Release - Upstream Major Version Blocker
A semantic-release plugin to prevent a new major version release if a specified upstream GitHub repository does not have a matching or higher major version SemVer tag on a given branch.
This plugin helps ensure that your project's major versions do not prematurely get ahead of a critical upstream dependency, maintaining versioning harmony and preventing accidental releases of software that may rely on unreleased upstream features.
Why?
When your project (e.g., a client library, a microservice component) has a
critical upstream dependency, its major version changes are often closely
tied to the major versions of that dependency. For instance, you might be
developing your-project v2.1.0 which is compatible with
upstream-dependency v2.x.x. If your-project is due for a major update
to v3.0.0, this new version is likely intended to align with, or require
features from, upstream-dependency v3.0.0 (or newer).
Releasing your-project v3.0.0 before upstream-dependency has itself
reached at least major version 3 (e.g., v3.0.0) on its relevant branch
can lead to several problems:
- Integration Issues: Your new
v3.0.0might be incompatible with the currently deployedv2.x.xof the upstream service because it expects features or breaking changes from the (as yet unreleased) upstreamv3.0.0. - User Confusion: Users might upgrade
your-projecttov3.0.0expecting it to work with the latest stable version of the upstream dependency, only to discover it's designed for a future, unreleased upstream version. - Deployment Blockers: You might intend for
your-project v3.0.0to be released in tandem withupstream-dependency v3.0.0. However, if your project's release pipeline triggers first, yourv3.0.0could be published prematurely, leading to a version that doesn't work correctly in the current ecosystem.
This plugin provides a safeguard by checking a designated upstream GitHub repository and a specific branch within it. If your automated release process (via semantic-release) determines that a major version bump is due for your project, this plugin will first verify that the upstream dependency has already published a release tag indicating that major version (or a higher one) on its specified branch. If this condition is not met, the release of your project is blocked, preventing these potential issues.
Installation
Install using NPM by using the following command:
npm install --save @mridang/semantic-release-peer-versionUsage
To use this plugin, add it to your semantic-release configuration file (e.g.,
.releaserc.js, release.config.js, or in your package.json).
The plugin should typically be placed before the @semantic-release/npm or
@semantic-release/github plugins in the plugins array, as it needs to run
its checks in the verifyConditions and analyzeCommits steps.
Example Configuration (.releaserc.js):
module.exports = {
branches: ['main', 'next'],
plugins: [
'@semantic-release/commit-analyzer', // Must come first to determine release type
[
'@mridang/semantic-release-peer-version',
{
repo: 'owner/repo',
// Optional: GitHub token for private repos or to avoid rate limiting
// Defaults to process.env.GITHUB_TOKEN || process.env.GH_TOKEN
// githubToken: process.env.UPSTREAM_GITHUB_TOKEN
},
],
'@semantic-release/release-notes-generator',
'@semantic-release/changelog',
'@semantic-release/npm', // If publishing to npm
'@semantic-release/github', // For creating GitHub releases and comments
'@semantic-release/git', // To commit package.json, CHANGELOG.md, etc.
],
};Known Issues
- GitHub API Rate Limiting: The plugin interacts with the GitHub API to
fetch release information (which includes tags) and potentially compare
commits. Unauthenticated API requests are subject to stricter rate limits.
To prevent disruptions, especially in CI environments or with frequent
usage, providing a
githubTokenis highly recommended. This enables the more lenient rate limits associated with authenticated requests. - Upstream Repository Tagging and Versioning: This plugin relies on the upstream repository adhering to Semantic Versioning for its release tags. These SemVer tags should be associated with published releases on the repository. If the upstream repository does not consistently use SemVer for its release tags, the plugin may be unable to accurately determine versioning information, such as a major version cap.
- Release Pagination: The plugin currently fetches data for up to the 100 most recent releases from the upstream repository to identify relevant SemVer tags. If the specific SemVer-tagged release crucial for the plugin's logic (e.g., for version capping or comparison) is older than these 100 most recent releases, it might not be detected.
- Token Permissions: When a
githubTokenis provided, it must have sufficient permissions to access the upstream repository's data. For private repositories, thereposcope (granting full control of private repositories) is typically required. For public repositories, while a token might not be strictly necessary for basic read access, providing one for authenticated requests (which helps with rate limits) means the token must still have adequate permissions to read repository content, list releases, and compare commits if these operations are performed by the plugin.
Useful links
- Semantic Release: The core automated version management and package publishing tool.
- Semantic Versioning (SemVer): The versioning specification that semantic-release adheres to.
Contributing
If you have suggestions for how this app could be improved, or want to report a bug, open an issue - we'd love all and any contributions.
License
Apache License 2.0 © 2024 Mridang Agarwalla