mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #606] Who is actually responsible to give the Semantic Version? #6418
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6418
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ahmadfauzi on GitHub (Aug 12, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/606
In software development, who is actually responsible to give the Semantic Version? Is it a Quality Assurance or Software Developer? Or another person such as Project Manager, Tech Director, etc ?
@ljharb commented on GitHub (Aug 12, 2020):
Those roles don't even necessarily exist in a general sense. I'd assume that whoever publishes the project decides the version number, but an organization can have any policies they like around that.
@Vampire commented on GitHub (Aug 21, 2020):
The code dictates the semantic version as that is the "semantic" part, how the public API changed between two versions. It is up to you how you manage it technically. But basically you could increase the patch version directly after release, increase the minor version as soon as you do anything that is backwards compatible but not a bugfix, increase the major version as soon as you do a breaking change, then you cannot forget to do it later.
@jwdonahue commented on GitHub (Sep 7, 2021):
For simple projects with one or few developers involved, responsibility can be distributed among the developers. Depends to some extent on your tooling. Do you use cloud based dev-ops or local builds? Either of those can be automated, such that developers specify what types of changes they have made, possibly augmented by AI and test suite results, and then the publish/deploy system uses the next best version number for the changes that have been made. Or you may be entirely up to executive decision. In many cases, breaking changes require upper management approval, new features require middle management, but bug fixes can be pushed by the devs without permission.
@jenstroeger commented on GitHub (May 14, 2023):
Assuming the contributors of your project understand the implications of their commits, you can use conventional commits and tools like commitizen to compute the next version bump of your project automatically.
@steveklabnik commented on GitHub (May 15, 2023):
This question has been pretty thoroughly answered, no guidance from the spec because it is agnostic to development processes and organization charts. Closing!