Suggest a concrete LTS version to be used as Jenkins baseline #3630
Conversation
probot-autolabeler
bot
added
the
documentation
|
Yes, this is my plan. I am already typing... |
|
I like the guidelines very much. The technical checks for a minimum Jenkins version which is "too new" in a dependency may be helped by jenkinsci/maven-hpi-plugin#191 |
content/doc/developer/plugin-development/choosing-jenkins-baseline.adoc
Outdated
Show resolved
Hide resolved
Co-authored-by: Mark Waite <[email protected]>
| ## Changing the minimum required version | ||
| If you do not have special requirements then a good idea is to support the latest three | ||
| LTS minor versions. This helps to ensure that teams that are slower at adapting new Jenkins versions | ||
| will not be forced to update their Jenkins too frequently. Additionally, other plugins that |
There was a problem hiding this comment.
I strongly disagree with this advice.
As Jenkins project / core maintainers / security team, we've only ever supported a single LTS release line. That's what gets security fixes. Right now, nobody should be on a release older than 2.235.x given multiple security updates in that line.
If you report a bug and are 3 lines behind, and it's not something that's obviously unchanged, we will tell you to update.
Please also note that this file uses sentence-per-line formatting.
There was a problem hiding this comment.
I'm not understanding your point of disagreement, @daniel-beck, can you explain further?
I think this paragraph is trying to guide plugin maintainers to choose a minimum required Jenkins version that includes a significant portion of their users. I don't think it is trying to claim that the Jenkins project or the Jenkins security team provide support for Jenkins core releases of anything other than the current LTS release line.
As a specific example, when choosing the minimum Jenkins version that the git plugin would support, I checked the installation statistics for the git plugin and decided based on installation patterns that Jenkins 2.204.1 was a good choice for the minimum required Jenkins version because that would not force a Jenkins version upgrade for over 60% of the users that were running a recent release of the plugin.
Would your recommendation have been that I make a different selection of minimum Jenkins version?
I don't think that you're recommending that plugins prefer to require the most recent LTS release line as their minimum Jenkins version, but maybe I've misunderstood your intent?
There was a problem hiding this comment.
Depends on security content in recent releases; but to me it sends mixed signals when we recommend plugin maintainers choose a baseline that is known to have security vulnerabilities specifically to allow administrators to postpone updating.
There was a problem hiding this comment.
The baseline is only a compile dependency, so I do not understand your point. I think everybody developing Jenkins plugins recommends the latest LTS when someone asks which version to install.
Or do you mean that we should remove the reasoning "This helps to ensure that teams that are slower at adapting new Jenkins versions will not be forced to update their Jenkins too frequently."
There was a problem hiding this comment.
Or do you mean that we should remove the reasoning "This helps to ensure that teams that are slower at adapting new Jenkins versions will not be forced to update their Jenkins too frequently."
Yes, the justification we give here undermines our general message to keep Jenkins up to date and especially to take security issues seriously. I don't think we've gone two consecutive LTS baselines in recent years without at least one security update.
| Example: if we are currently at Jenkins 2.248 then the latest LTS version is | ||
| 2.235.x. Then it would make sense to also support 2.222.x and 2.204.x. When setting the Jenkins version | ||
| please also make sure to use the .1 patch version of the LTS version: 2.204.1, or 2.222.1. Using | ||
| a newer patch version like 2.222.6 causes build problems in depending plugins that depend on the |
There was a problem hiding this comment.
This explanation makes no sense to me, I responded in the mailing list thread.
There was a problem hiding this comment.
Here are some problems that are caused by plugins updating their baseline. My plugin had a baseline of 2.204.4, the same baseline was used in my ATH tests. It depends directly or indirectly on two API plugins: snakeyaml-api-plugin and jackson2-api-plugin. These plugins have been recently updated to 2.204.6 and 2.222.4, respectively. This caused failures for the maven-enforcer, the generated injected integration tests, and the UI tests for my plugins. And not because of a bug - just because of an inconsistent Jenkins baseline selection.
There was a problem hiding this comment.
I do not get it. If your baseline is 2.204.x then just do not pick newer versions of these plugins as test-scoped dependencies, unless and until you update your own baseline. Of course if you use the bom then you do not need to even think about this issue for covered dependencies.
| Additionally, since features are sometimes moved from core into plugins, depending on a more recent Jenkins version will make your plugin's dependencies on what used to be core features explicit, otherwise your plugin will not work. | ||
| * *Use at least the minimum version supported by the update center*, the supported update center versions can be found at link:https://updates.jenkins.io[updates.jenkins.io], at the time of writing (2020-03) this is 2.164.x. | ||
| * *Use at least the minimum version supported by the update center*, the supported update center versions can be found at link:https://updates.jenkins.io[updates.jenkins.io], at the time of writing (August 2020) this is 2.176.x. |
There was a problem hiding this comment.
This has the problem that it's not sure that these are always starting at .1, so this contradicts advice further down. Dynamic tiers do not go by baselines, but individual releases.
There was a problem hiding this comment.
This has the problem that it's not sure that these are always starting at .1, so this contradicts advice further down.
Which advice? I think a plugin developer will be smart enough to select the .2 version if there is no .1 version.
Maybe it would help that we explicitly set the recommended baseline version when we select the new LTS baseline. That means this document (or another one?) needs to change with every LTS minor version.
There was a problem hiding this comment.
I am referring to this advice:
When setting the Jenkins version please also make sure to use the .1 patch version of the LTS version: 2.204.1, or 2.222.1.
The way update-center2 currently works is that it only looks at the release date and goes back 1 year, so the oldest supported release there will not be a .1 release.
Of course this also says "at least" and if we consider these version requirements ("not older than", "only .1") as a sort of "Venn diagram" then the area of overlap will be the reasonable choices.
But I do wonder whether we can rewrite this page to present all of these considerations, and perhaps even make the versions we consider good choices explicit. Can probably even be automated, especially once jenkins-infra/update-center2#424 gives access to tiers.json.
There was a problem hiding this comment.
I would say at least use the oldest line supported by the bom…so you can use the BOM, and keep it fresh with Dependabot.
|
Once reason I hesitate to explicitly ask for |
There was a problem hiding this comment.
I guess I am -0 on this. From my experience, it is least hassle to just pick a pretty recent baseline and do your trunk development based on that. This also simplifies the life of core maintainers. If and when some users plead with you to offer some important, low-risk bug fix for older lines (acknowledging that they are exposed to disclosed security vulnerabilities), it is very easy to publish backports.
| Additionally, since features are sometimes moved from core into plugins, depending on a more recent Jenkins version will make your plugin's dependencies on what used to be core features explicit, otherwise your plugin will not work. | ||
| * *Use at least the minimum version supported by the update center*, the supported update center versions can be found at link:https://updates.jenkins.io[updates.jenkins.io], at the time of writing (2020-03) this is 2.164.x. | ||
| * *Use at least the minimum version supported by the update center*, the supported update center versions can be found at link:https://updates.jenkins.io[updates.jenkins.io], at the time of writing (August 2020) this is 2.176.x. |
There was a problem hiding this comment.
I would say at least use the oldest line supported by the bom…so you can use the BOM, and keep it fresh with Dependabot.
|
Superseded by #3643. |
Recently a lot of my builds failed (my baseline was 2.204.4) because some frequently used base plugins updated their minimum Jenkins version to a higher LTS minor version (like 2.222.1) or a higher patch version (2.204.6).
So it might make sense to make the baseline selection more precise.