Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
There seems to be a problem with the policy of only traversing the first merge parent when determining the rev count portion of an incremental version number: it is not guaranteed that this count will be higher than the count of an ancestor commit. While the count is always higher “within a branch”, this does not necessarily hold when merging one branch into another: an old derivative branch may have a shorter line of development while pulling in a long list of changes from an upstream branch. In turn this means that incrementals:update sometimes selects a commit which looks newer than the current dependency version, and is an ancestor of the selected branch head, and yet which is not the maximal such commit topologically.
Attachments
Issue Links
- links to
(1 links to)
Activity
Field | Original Value | New Value |
---|---|---|
Epic Link |
|
Remote Link | This issue links to "CloudBees Internal ARC-397 (Web Link)" [ 20908 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Remote Link | This issue links to "incrementals-tools PR 6 (Web Link)" [ 21198 ] |
Remote Link | This issue links to "jep PR 145 (Web Link)" [ 21201 ] |
Remote Link | This issue links to "plugin-pom PR 119 (Web Link)" [ 21203 ] |
Remote Link | This issue links to "workflow-job PR 102 (Web Link)" [ 21204 ] |
Status | In Progress [ 3 ] | In Review [ 10005 ] |
Remote Link | This issue links to "pom PR 28 (Web Link)" [ 21205 ] |
Resolution | Fixed [ 1 ] | |
Status | In Review [ 10005 ] | Resolved [ 5 ] |