On Mon, Aug 26, 2019 at 4:46 PM Mark Waite <mark.earl.wa...@gmail.com> wrote: > I've generally preferred to keep the dependency at oldest version I can > reasonably trust.
Well, the BOM is designed to give you the newest version compatible with your LTS line. > I believe in this case that the credentials plugin 2.2.0 is the required > dependency from the BOM because it is the version which includes the most > recent security fix for the credentials plugin. No, it is just the latest available version according to Dependabot. > Am I correct [that using the BOM] means [users] will generally have newer > dependencies than they did in the past? Yes. Now as to whether you _want_ to publish new releases of one plugin that depend only on old releases of another plugin, this is certainly a matter of judgment. You would be offering a special benefit to the user that spends an hour looking over the *Updates* tab, poring through release notes, and hand-picking certain updates according to features or fixes they think they want. But your plugin’s tests will only be verifying compatibility with a rather old snapshot of the Jenkins ecosystem, and you will likely even be writing new code which calls APIs that were deprecated years ago. The assumption behind the BOM is that most people just accept all updates most of the time, and if something breaks they will just roll everything back, or tolerate it until a fix is released; plugin maintainers should “fixing forward”. (Jenkins core is somewhat artificially given a special position in this view, as something that is cumbersome and particularly risky to update.) -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2FysL-2e6PPtkdHHYXFEJkFhhcstK1BV3eu-WWLT%3Dopw%40mail.gmail.com.
