Here are the comments copied from the GItHub Issue where this originated (https://github.com/jenkinsci/maven-dependency-update-trigger-plugin/issues/5)

ssotangk commented on Oct 22
In a continuous deployment environment, each build artifact should have a release number instead of a snapshot. Teams should have a choice to build when a dependency is built even if the dependency is not a snapshot dependency.
@emoshaya-cognito
emoshaya-cognito commented 13 days ago
completely agree with @ssotangk we will also stop using snapshots in our builds in order to have every commit a potential release. It would be nice to have the update trigger support release dependencies too.
@victornoel
victornoel commented a day ago
Well… if it's not a SNAPSHOT, you have to update the version in the dependant project for the latest version to be used, and then commit it, which should trigger a build: you don't need maven-dependency-update-trigger-plugin for that!
@ssotangkur

ssotangkur commented 22 hours ago
Hi @victornoel, I'm saying that if we can trigger the dependent project to run, then the project can do the dependency check and update its own dependency's versions.

You're right in that if we could know when a dependent project should update its dependencies, then we could update them and that would trigger a commit and then cause it to be built w/o maven-dependency-update-trigger-plugin. The one only thing that's missing, however, is we still need that thing that lets us know we should update a particular project (out of possibly many other projects) because its dependency(s) have been updated. An "update-trigger" is nice for this because, it not only let's us know which ones need updating, but also goes ahead and triggers them to start that process.

victornoel commented 7 hours ago
Maybe you could implement your need with more generic trigger plugins from Jenkins, but what you are talking about is out of the scope of this plugin I think. I understand your need, but here is the wrong place
(anyway, the correct way to ask for feature is the jenkins jira, not here, the github issues for this project should be disabled I think, don't you think @alecharp).
@alecharp
Collaborator
alecharp commented 3 hours ago
I agree @victornoel, Github issues should not be used, only Jira. @ssotangkur, please create a ticket on Jira.

However, I don't think you can really use this plugin for what you need. Maven don't detect new versions per say, as it download the metadata file for an artifact version and see if it's newer than the one in the current repository. But it does not look for newer versions. Even, you specifically put a release version on your pom to make sure this is the one you use in production. If at some point, Maven upgrade a dependency without your consent, you could have regression because of the new version of the dependency.

I agree that for continuous deployment, you need to consider every deployed version as release, to be able to find the code and fix them. But I don't think this plugin will help you achieve that. Sorry.

@alecharp, @victornoel, I believe that because this plugin is named "maven-dependency-update-trigger-plugin" then it should support all cases were the maven dependency was updated, not just the specific case where the dependency happens to be a snapshot dependency. That makes this feature request within the scope of this plugin.
Now, implementation-wise, supporting this request might be a huge departure from the current snapshot-only implementation, however differences in implementation should not dictate scope definition.
I suppose, if you really did not want this to be part of the scope, then the plugin should be renamed to "maven-snapshot-dependency-update-trigger-plugin" to avoid the implication that it can handle all types of dependencies.

...If at some point, Maven upgrade a dependency without your consent, you could have regression because of the new version of the dependency.
This is not an issue for me as I can constrain which dependencies I choose to update based on criteria such as group id. The plugin should provide similar capabilities.
If you look at the "Controlling which dependencies are processed" section of http://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
you can see that simply combining your trigger plugin with non-snapshot support and this codehaus maven plugin, I can get exactly what I need.

If you need code to figure out how to check for updated dependencies, that codehaus plugin already does it (we just need you to integrate it with the triggering logic in jenkins).
Codehaus updated dependency checking -> http://www.mojohaus.org/versions-maven-plugin/examples/display-dependency-updates.html

I've been looking for a plugin with the similar capability to achieve continuous delivery of our Maven artifacts. Currently we are having a workaround by maintaining a conditional downstream job i.e. have a Groovy script to trigger the downstream jobs only if the scheduled build is a release build. The downstream jobs that we are triggering are the jobs similar to the description given by ssotangkur, which are to update the dependency versions automatically.

Maintaining the downstream jobs is painful as we need to update them every time there is a new repository to be built..