Alternately, create a script which suggests version updates from a given branch—calculating the expected version strings and then checking to see if they have actually been deployed or not, and/or offering the last commit to be deployed on the first-parent traversal chain.

Just to make sure some requirements are clear. The output of such a tool, for Jenkins Essentials, will be something that includes a full URL for each artifact so that we can properly offer downloads.

Starting work on such a tool.

The main work should be encapsulated in a reusable function which would be callable from several front-ends, one of which would offer to update deps in a POM, another for essentials.yaml.

With this tool in place allowing to update the incrementals versions easily, I agree to use CWP to implement the missing parts in JENKINS-51008 as there would be a deterministic way to get the proper versions to use to test

At this point I have a script which, given a current GAV and a target branch (incl. PR!), will dig through Artifactory and GitHub metadata to determine the best available update (whether that be a JEP-305-based incremental version, or simply from MRP). The next step is to embed this in a tool which takes a metadata file and actually edits it to select updates for one or more components.

Since I am struggling to find an example of a YAML config file already using incremental versions which could be used as a test bed, and I left some comments in the BOM JEP draft about a suggested modification to the format that would be more amenable to this tool, I am going to start with a Maven POM processor that could be used for JENKINS-47498 as well as simple chained pull requests.

Example of BOM load/save code.

I left further comments pointing out that versions used for integration tests would better be obtained from Maven POMs anyway. Even Evergreen could use a POM as the source of truth, but if some other YAML format is preferred, I just need a working example (currently essentials.yml is just for show).