Closed snicoll closed 5 years ago
This has been implemented apart from the following part:
When a dependency has been ignored, it is important to log it and, perhaps, output a report at the end that summarizes the decisions that were made.
A benefit of the upgrade policy is that it makes upgrades in maintenance releases far less noisy. Logging versions that have been ignored will make things noisier again so I'm not sure how to strike a balance there. I'd like to get some experience with using Bomr now that policies are supported and then tackle this part of the suggestion separately.
When using
bomr
on a maintenance release, a large amount of dependency upgrades may have to be ignored as they don't fit the upgrade policy.Example: Project
3.4.0.RELEASE
usescom.example:acme:1.5.0
and the release policy is to only upgrade to bug fix releases in a maintenance release of the project.Let's now assume that
acme
published later the following releases:1.6.0
,1.7.0
,1.7.1.
and2.0.0
. Currently, everytimebomr
runs on3.4.x
it suggests to upgradeacme
but the versions that are available do not fit the policy.An enhancement would be to be able to flag a dependency as to be ignored because it doesn't match a configurable policy. The tool could provide a couple of frequent policies or it could be build with a custom implementation of said policy.
When a dependency has been ignored, it is important to log it and, perhaps, output a report at the end that summarizes the decisions that were made. Finally, a flag that ignores the policy could be interesting if we want to be more in control.