Bump a Semantic Version by Major, Minor, or Patch
Get the next release number without slips: a minor bump turns 2.7.4 into 2.8.0, resetting the patch to zero, and any prerelease or build suffix is dropped because a new release line begins. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Version
- 2.7.4
- Bump type
- Minor
- Original version
- 2.7.4
- Bumped version
- 2.8.0
The Semantic Version Bump tool calculates the next release number from a valid Semantic Versioning 2.0.0 string and a chosen bump type. Select major, minor, or patch, and it increments the requested component while resetting every lower component to zero. Prerelease labels and build metadata are removed because the result represents a new normal release line. Strict validation catches malformed versions and unsupported bump names before they can enter release scripts, package publishing workflows, changelog automation, or continuous delivery pipelines.
Choose the release change you intend to communicate
Semantic Versioning gives each of the three core numbers a distinct meaning, so the correct bump begins with the kind of change being released. The calculator increments the major component and resets both minor and patch to zero, turning 4.8.6 into 5.0.0. Choose minor when functionality is added in a backward-compatible way.
That increments the minor component and resets patch, so 4.8.6 becomes 4.9.0. Choose patch for backward-compatible bug fixes, producing 4.8.7 from the same input. The operation is deliberately mechanical: it does not inspect source code, commits, or changelog text and cannot decide whether a change is breaking.
That classification remains part of your release policy. Once selected, however, the arithmetic is consistent and repeatable. This separation makes the tool useful in systems where a human, pull-request label, or conventional-commit analyzer determines the release category and needs a dependable final calculation.
Understand strict input validation and suffix removal
The version must follow Semantic Versioning 2.0.0 exactly, with major, minor, and patch components present. Valid examples include 1.2.3, 2.0.0-rc.1, and 3.4.5+linux.x64. Loose forms such as v1.2.3, 1.2, or core numbers with leading zeroes are rejected instead of being silently repaired.
Prerelease identifiers and build metadata are validated as part of the input, but neither suffix is retained in the bumped result. A bump starts a new core release number: patching 2.1.0-beta.3 produces 2.1.1, while a minor bump produces 2.2.0. This behavior avoids ambiguous output such as carrying an old release-candidate label onto a newly incremented release line.
The bump type is also a strict finite choice: major, minor, or patch in lowercase. Strictness is especially valuable in automation because spelling errors, package-manager shorthand, and incomplete versions stop visibly instead of creating an incorrect tag that may be difficult to retract after publication.
Use deterministic version arithmetic in release automation
The calculator is designed as a small deterministic step that can sit inside a larger release workflow. Processing uses no network calls, clock, random value, external model, or stored state, so identical inputs always produce identical outputs. Numeric components are incremented as decimal digit strings rather than converted to JavaScript numbers.
That detail preserves exact behavior even for valid components larger than the safe integer range, eliminating rounding surprises in unusual but standards-compliant version values.
What you can do with it
Prepare a package release
Calculate the next manifest version after maintainers approve a major, minor, or patch release.
Drive a continuous delivery pipeline
Turn a release classification from labels or commit analysis into a deterministic version for later build steps.
Validate a proposed release number
Compare the calculated bump with a version proposed in a pull request before creating tags or publishing artifacts.
FAQ
What does each bump type do?
Major increments major and resets minor and patch. Minor increments minor and resets patch. Patch increments only patch.
Are prerelease labels retained?
No. A valid prerelease suffix is accepted on input but removed from the newly bumped core version.
Does build metadata affect the result?
No. Valid build metadata is accepted and then removed when the new version is calculated.
Can I use a leading v or omit the patch number?
No. The input must be a strict Semantic Versioning 2.0.0 string with all three core components.
Does it decide which bump my change needs?
No. It does not read code, commits or changelog text and cannot tell whether a change is breaking. You or your release rules choose major, minor or patch; it then does the arithmetic the same way every time.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev2/semver-bump \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"version":"2.7.4","bump_type":"minor"}'const res = await fetch("https://api.kit.forhosting.com/dev2/semver-bump", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"version": "2.7.4",
"bump_type": "minor"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/semver-bump",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"version": "2.7.4",
"bump_type": "minor"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/semver-bump", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"version":"2.7.4","bump_type":"minor"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"version":"2.7.4","bump_type":"minor"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/semver-bump", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"version": "2.7.4",
"bump_type": "minor"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.semver_bump",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Choose the release change you intend to communicate
Choose a major bump when the new release contains incompatible public API changes.
Understand strict input validation and suffix removal
Any other name returns an invalid_input error.
Use deterministic version arithmetic in release automation
Send the current version and the approved bump type, then use bumped_version for a package manifest update, release branch, artifact label, or proposed repository tag. The response also repeats original_version and bump_type, making logs and approval screens easier to audit without reconstructing the request. When a build service, CLI, or continuous integration job needs the same calculation programmatically, call the API at $0.002 per item and treat invalid_input as a release-data issue requiring correction before publishing.
Technical questions
What happens for an unknown bump type?
The request returns an invalid_input error. Only major, minor, and patch are recognized.
How much does the API cost?
The API price is $0.002 per item, while the browser runner is available for interactive checks.