Brent N Atkinson created CONTINUUM-2752:
-------------------------------------------
Summary: Always assign a new build number when starting a build
Key: CONTINUUM-2752
URL: https://issues.apache.org/jira/browse/CONTINUUM-2752
Project: Continuum
Issue Type: Improvement
Affects Versions: 1.5.0
Reporter: Brent N Atkinson
Fix For: 1.5.0
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)