Impact of BOM on plugin versions

[Mark Waite]

I think that it would be easier to maintain the workflow test dependencies inside the git plugin by using the new BOM that Jesse has created.

As a test, I tried to use the BOM with the git client plugin.  That change allowed me to remove the explicit version numbers from 4 dependencies.  That is a nice very nice improvement for a plugin that has relatively few dependencies.

However, when I look at the dependencies which are assigned by the 2.138.1 version of the BOM, it assigns

• ssh-credentials 1.17.1
• credentials 2.2.0

I've generally preferred to keep the dependency at oldest version I can reasonably trust.  In this case, the BOM is choosing the second most recent release of the credentials plugin 

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.

A different security advisory recommends that ssh-credentials should be newer than 1.13.  Is there a specific reason that 1.17.1 was selected rather than 1.14?

Am I correct to assume that it is safe, reasonable, and healthy for the git client plugin (and the git plugin) to use the BOM and accept that means they will generally have newer dependencies than they did in the past?

Mark Waite

--

Thanks!

Mark Waite

[Jesse Glick]

On Mon, Aug 26, 2019 at 4:46 PM Mark Waite <mark.ea...@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.)

[Matt Sicker]

I've made two new releases for credentials since then (2.2.1 and
2.3.0, the latter of which was released just yesterday). Also, I
started using that bom in credentials-plugin, so it's somewhat amusing
that it imports a dependencyManagement for itself, though it doesn't
appear to adversely affect the build at all.

> --
> 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-de...@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.



--
Matt Sicker
Senior Software Engineer, CloudBees

[Jesse Glick]

On Tue, Aug 27, 2019 at 11:09 AM Matt Sicker <msi...@cloudbees.com> wrote:
> I've made two new releases for credentials since then (2.2.1 and
> 2.3.0, the latter of which was released just yesterday).

…which may have broken something, by the way:

https://github.com/jenkinsci/bom/pull/77

> it's somewhat amusing
> that it imports a dependencyManagement for itself, though it doesn't
> appear to adversely affect the build at all.

Still waiting for

https://github.com/apache/maven-integration-testing/pull/25

:-(

[Matt Sicker]

And here I thought you were already on the Maven PMC. Perhaps you
could try reminding them on the dev lists?

Also, are you suggesting that I shouldn't use the bom in credentials?
Or is that issue resolved?

> --
> 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-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1cDFNCj0GhfWdAJK3TXTTZRvyvmnZW7FX%3DBoR4GwEBTg%40mail.gmail.com.

[Jesse Glick]

On Wed, Aug 28, 2019 at 11:15 AM Matt Sicker <msi...@cloudbees.com> wrote:
> I thought you were already on the Maven PMC.

Perhaps you were thinking of Stephen.

> are you suggesting that I shouldn't use the bom in credentials?

No, I was just linking to an IT demonstrating that—so far as I can
tell—it is safe to consume an older release of a BOM in a component
which is then in turn included in a newer release of the same BOM.

[Matt Sicker]

Ok, thanks for the clarification. And I assumed it based on all the
Maven knowledge you have. ;)

> --
> 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-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3aPg%2BF6-Zd2K%2BpcqSFcQTNA8uh2a%3D4jTfYv-MwMY_TRA%40mail.gmail.com.