[
https://issues.apache.org/jira/browse/CONTINUUM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent N Atkinson closed CONTINUUM-2752.
---------------------------------------
Resolution: Fixed
Fixed in r1674175
> 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
> Assignee: 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)
