Hi, Summary:
The curated list of dependencies which requires manual update or currently blocked (Java 21+/Maven 4) is available here: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20issuetype%20%3D%20%22Dependency%20upgrade%22%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20ORDER%20BY%20updated%20DESC%2C%20created%20DESC When fixing one of them, reopen the corresponding dependabot PR where the @dependabot ignore was provided. More details: I'm currently looking to dependabot job and dependencies. I investigated why several dependencies were no more updated. There were few dependabot bug/limitations (most impacting was due to artefact relocation) and several dependencies for which we set `@dependabot ignore xxx`. Unless I missed something else, with current state, all new versions of dependencies will either: * result in a PR creation by dependabot OR * there is a PR still opened not handled OR * there is a Jira associated and an instruction to ignore it Some ideas/proposals/learnings/feedback from that: * When we use a `@dependabot ignore xxx` * it is very useful to provide a JIRA issue of type `Dependency Upgrade`. We have done most of the time iin the past but we missed some of them. * Also based on next comment, useful to provide the link to the PR where we declared the `@dependabot ignore` * After updating manually based on a JIRA ticket, we need to reopen the corresponding dependabot PR, otherwise the `dependabot ignore` is still active and there won't be new updates from dependabot * I was calling @dependabot rebase on them to have the result right away and do not wait for the next dependabot global job trigger * Another alternative would be to add the dependency to ignore section of dependabot.yaml https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#ignore-- which might be easier to clean/follow-up than comment in PRs but still not easy to remember to remove it after the manual update. * >From my current understanding, there is a gap in the process in what >dependabot is proposing, might be worthy to investigate a bit more. * When a dependency upgrade is blocked by a "bigger change", I linked to a dedicated issue when available but also provided a little prefix to the title, like [JDK 21] Upgrade XXX to y+ . We can keep it this way if fine for the majority. * To find all these dependencies, I used several methods: * Look to git blame and find which property version were not updated for a long time in parent/pom.xml (this was mainly useful to detect unmaintained libraries, might be a topic for another mail another day to share current state) * Activated dependabot on my fork * And review all created PR by dependabot to understand why they are not present on the apache/camel side * You can see https://github.com/apupier/camel/pulls which is more or less the list of JIRAs * And I used this filter `is:pr is:open -label:JIRA_EXISTS -label:EXPLAINED `<https://github.com/apupier/camel/pulls?q=is%3Apr+is%3Aopen+-label%3AJIRA_EXISTS+-label%3AEXPLAINED> regards, Aurélien Pupier, Senior Software Engineer for Apache Camel Quarkus Unless otherwise stated above: Compagnie IBM France Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 614 175,50 € SIRET : 552 118 465 03644 - Code NAF 6203Z
