Plugin BOM upgrade, 2.289.1 vs. 2.289.3

[Mark Waite]

Dependabot proposed a git plugin pull request to update the 2.289.x bom from 1117.v62a_f6a_01de98 to 1135.va_4eeca_ea_21c1.

The pull request CI build fails because configuration as code plugin requires Jenkins 2.289.3 or higher but the git plugin only requires 2.289.1 or higher.

I'm interested in recommendations for actions I should take in this case.  I could:

• Use dependabot to ignore the proposed upgrade and remain with the previous version of the plugin bom
• Increase the minimum required Jenkins version from 2.289.1 to 2.289.3
• Increase the minimum required Jenkins version from 2.289.1 to 2.303.1 and use the matching plugin bom for 2.303.1
• Do something else that I've not considered

Are there particular strengths of one of those options over the others?  

Are there weaknesses in one or more of those options that would guide me to not choose that option?

Mark Waite

[Jesse Glick]

I am not sure there is a consensus yet in this area; see discussion in https://github.com/jenkinsci/archetypes/pull/376#discussion_r781199364 and elsewhere. My inclination is to require 2.289.3; there does not seem to be much point in testing against an outdated LTS point release, especially one that predates a security advisory and which no one should be running in production. I will file a docs PR making that policy change and see where the discussion goes.

[Ullrich Hafner]

Am 31.01.2022 um 15:46 schrieb Mark Waite <mark.ea...@gmail.com>:

Dependabot proposed a git plugin pull request to update the 2.289.x bom from 1117.v62a_f6a_01de98 to 1135.va_4eeca_ea_21c1.

The pull request CI build fails because configuration as code plugin requires Jenkins 2.289.3 or higher but the git plugin only requires 2.289.1 or higher.

We should inform the configuration as code plugin team to use the recommended Jenkins baseline versions, i.e., 2.289.1 or 2.303.1. 

I'm interested in recommendations for actions I should take in this case.  I could:

• Use dependabot to ignore the proposed upgrade and remain with the previous version of the plugin bom
• Increase the minimum required Jenkins version from 2.289.1 to 2.289.3
• Increase the minimum required Jenkins version from 2.289.1 to 2.303.1 and use the matching plugin bom for 2.303.1
• Do something else that I've not considered

Are there particular strengths of one of those options over the others?  

Are there weaknesses in one or more of those options that would guide me to not choose that option?

Mark Waite

--
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/04973ee4-fcc0-4fd9-a3ea-f95bc7311aa9n%40googlegroups.com.

[Ullrich Hafner]

The docs are here: https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/

While I understand the reasoning for using the latest patch version of an LTS I think this increases the number of unneeded version upgrades for plugin authors. Due to this unnecessary version change in configuration as code the git plugin needs to increase the version. When Mark releases this change in the git plugin as well, I need to change my git-forensics plugin as well, … and so on. The number of plugin upgrades increases just because the LTS patch version increases, this is just a lot of additional work for nothing.

Am 31.01.2022 um 16:02 schrieb 'Jesse Glick' via Jenkins Developers <jenkin...@googlegroups.com>:

I am not sure there is a consensus yet in this area; see discussion in https://github.com/jenkinsci/archetypes/pull/376#discussion_r781199364 and elsewhere. My inclination is to require 2.289.3; there does not seem to be much point in testing against an outdated LTS point release, especially one that predates a security advisory and which no one should be running in production. I will file a docs PR making that policy change and see where the discussion goes.

--
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/CANfRfr3xQW9u%2B-7jBjvqoiqO%2B283ZNJ0HYvkweR2-Gh_%2By1bjA%40mail.gmail.com.

[jn...@cloudbees.com]

>  While I understand the reasoning for using the latest patch version of an LTS I think this increases the number of unneeded version upgrades for plugin authors.

warning: unpopular optinion follows 

as does accepting *any* update to the BOM in your plugin when you do not need a new API provided by a plugin that has been updaded/added in the bom.

Testing (binary api) of the compatibility set is done in the BOM itself, so you should already know your code tests correctly (at a binary level, maybe not source code) so this is mostly in my experience busy work for no gain.

[Jesse Glick]

On Mon, Jan 31, 2022 at 10:26 AM 'jn...@cloudbees.com' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

Testing (binary api) of the compatibility set is done in the BOM itself

For plugins in the BOM.

There are other reasons to want to use a reasonably recent BOM: you may see newly available APIs, or new deprecation warnings, or new behaviors that do not happen to result in test failures.

[Jesse Glick]

On Mon, Jan 31, 2022 at 10:02 AM Jesse Glick <jgl...@cloudbees.com> wrote:

I will file a docs PR making that policy change and see where the discussion goes.

https://github.com/jenkins-infra/jenkins.io/pull/4876