Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.5.0
-
None
-
None
Description
The way that build numbers are assigned is not intuitive and it adds unnecessary complexity to the system. By always assigning a new build number to new builds, it becomes a simple, intuitive and reliable identifier and complexity can be reduced.
Why it is not intuitive:
Currently, a new build number is only assigned to a build when the build outcome is successful. This means that a build number can not be used to reference an arbitrary build: in-progress or failed builds don't have a unique build number. While perhaps handy for conserving build numbers, this scheme's utility for identifying builds is dubious. As an alternative, the internal build id can be used to uniquely identify any build, but it is also not intuitive because its domain covers all build results regardless of project. It will appear to leap past what most people would expect to be the next build number for the project.
The reason it complicates the system:
Unsurprisingly, for the same reason it is not intuitive for humans: it is an unreliable way of uniquely identifying builds. Every part of the system dealing with build numbers has to account for the conditional nature of the number. This leads to branching logic wherever it is used adding complexity. Because the build number is unknown until a build finishes, another more reliable mode of identification is required. Also, it complicates build result handling, particularly when using distributed build agents, because assignment must be handled at the end of the build and the result must identified uniquely to correctly assign it.
Attachments
Issue Links
- is related to
-
CONTINUUM-2297 Build Number in Surefire Report does not reflect the actual build number of the build result it is attached to
-
- Closed
-
-
-
- Closed
-