Say I have a three PRs going into the next release. Each PR is a bug fix and all have been approved for the next release. If the current version is 2.3.1
, should the next version be 2.3.2
(count all three bugs as one patch increment) or 2.3.4
(one increment for each bug).
I have read the semver spec, but could find no mention of this specific scenario.
-
1"one increment for each bug" That sounds odd. Version increments should be done for milestones / sprints, otherwise that won't scale well for complex systems with many developers working on it.πάντα ῥεῖ– πάντα ῥεῖ2019年09月09日 18:19:12 +00:00Commented Sep 9, 2019 at 18:19
-
1Why would any one release increase any value by more than one? It's not a count of changes.jonrsharpe– jonrsharpe2019年09月09日 18:41:19 +00:00Commented Sep 9, 2019 at 18:41
-
@jonrsharpe: The company I work for has a product where the R&D department increments the tiny version for every change, but not every change gets released to QA, and not every version that gets released to QA gets released by Product Management. So, the last releases were 1.8.294, 1.8.490, 1.8.628, 1.8.7(I forgot), and the next will be something above 1.8.763 (since that's the current R&D version).Jörg W Mittag– Jörg W Mittag2019年09月09日 18:44:38 +00:00Commented Sep 9, 2019 at 18:44
-
1@JörgWMittag that's more of a build number than a version number, then.jonrsharpe– jonrsharpe2019年09月09日 18:45:45 +00:00Commented Sep 9, 2019 at 18:45
-
1Are you going to make three incremental builds or just one with all three fixes?cdkMoose– cdkMoose2019年09月09日 20:09:37 +00:00Commented Sep 9, 2019 at 20:09
1 Answer 1
Version numbers should identify a package (executable, library,...) that a user could have access to. Any version numbering you share with your community is telling a user what versions exist. Creating the intermediate version numbers in your example is misleading because there isn't actually a version 2.3.3 that a user could download and run to get that fix without the other fixes.
Internally you may want to track per build version numbers or add a fourth level to your version which is the build number to provide more clarity. For larger systems, if you had a new version number for every modification, your version numbers would be out of control.
-
Not to mention what should be unleashed into public / produduction.πάντα ῥεῖ– πάντα ῥεῖ2019年09月09日 20:33:16 +00:00Commented Sep 9, 2019 at 20:33