Update jenkins.version to 2.528.3 post LTS release

[shalinisudarsan]

update jenkins version to 2.528.3

Testing done

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[alecharp]

I don't know why the latest LTS is using the .2 today but it definitively shouldn't. From line 1759:

Use .1 of most recent active line, and .3 (or later) of previous lines: https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/#choosing-a-version

[timja]

I don't know why the latest LTS is using the .2 today but it definitively shouldn't. From line 1759:

Use .1 of most recent active line, and .3 (or later) of previous lines: jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline#choosing-a-version

The bom tests against the latest LTS version it has always done that and it is part of the release process to update it.

[alecharp]

Then the comment needs to be removed.

[lemeurherve]

I think #5970 shouldn't have been done (my mistake sorry), but this .3 looks fine to me, then I may be missing something.

[alecharp]

To me the latest LTS was always kept to the .1 in sample-plugin. I don't know when the policy changed.

[lemeurherve]

I don't know when the policy changed.

This line dates from 3 years ago, 2e15402

[alecharp]

yes, as I said, for the past 3years the latest LTS was kept on .1 but here we changed to .2. Anyway, disregard my review.

[lemeurherve]

yes, as I said, for the past 3years the latest LTS was kept on .1 but here we changed to .2. Anyway, disregard my review.

Yes, that .2 was a mistake of mine as said above too 🙂

This new .3 is fine.

[krisstern]

Yeah, since this LTS .3 is a security release, I think it is best practice to update to this version for BOM

[alecharp]

Please disregard my review.

[alecharp]

Yeah, since this LTS .3 is a security release, I think it is best practice to update to this version for BOM

having a temporary branch with the .3 and full-test label is what I though we did in the past.

[lemeurherve]

@shalinisudarsan can you update your PR title to a more explicit one please?

Ex:

Update jenkins.version to 2.528.3 post LTS release

[krisstern]

LGTM!
Thanks @shalinisudarsan

[timja]

To me the latest LTS was always kept to the .1 in sample-plugin. I don't know when the policy changed.

Its in the release checklist: https://github.com/jenkins-infra/release/blob/ef00711df3a3186227b60650460fe2d7ec439dbc/.github/ISSUE_TEMPLATE/1-lts-release-checklist.md#L105-L106

Been there for years as far as I know.

[MarkEWaite]

@jtnord and @rsandell have both noted to me that they think it is a mistake in the plugin BOM documentation and in the LTS release checklist that we update to the last release of the LTS line instead of remaining on the first release of the LTS line.

I believe their reasoning is that there should be no API changes between the first release of the LTS line and the last release of the LTS line, so the version update does not help the plugin maintainer. Remaining on the first release of the LTS line avoids changes to plugin pom files to switch them from depending on the first release of the LTS line to the last release of the LTS line. We've seen those types of changes spread through the plugin suite when a plugin dependency switches from first LTS release to last LTS release and causes plugins that depend on it to do the same.

I don't see any major issues that would result from us choosing to remain on the first release of the LTS line instead of updating to the last release of the LTS line. Plugin BOM maintainers would suffer a minor inconvenience because they would need to close the GitHub security warnings that will appear when a Jenkins LTS release includes a security fix but is not updated in the plugin BOM. As an example, GitHub opened 5 security warnings in the plugin BOM repository when Jenkins 2.528.3 was released. If we were remaining on the first release of the LTS line, we would dismiss those security issues rather than closing them with an upgrade of the Jenkins version.

Are there other negative impacts if we were to change our policy, update the documentation, and keep 2.541.x BOM line on the .1 release?

[jglick]

We've seen those types of changes spread through the plugin suite when a plugin dependency switches from first LTS release to last LTS release and causes plugins that depend on it to do the same.

This happens often for prior LTS versions. It does not normally happen for the current LTS release, because we recommend against it. This module in bom is not deployed and so does not control what jenkins.version you pick for your plugin; even if sample-plugin is testing against 2.528.3, you can still import the BOM and use it just fine while using the recommend 2.528.1 baseline, so long as all of your transitive dependencies do the same. What could matter is if some plugin bumped to 2.528.3 and then this bump lands in a 2.528.x BOM update, forcing any plugins which do depend on that plugin to either reject the BOM update or themselves pick 2.528.3. Holding back sample-plugin to 2.528.1 would have the effect of breaking any PR proposing a bump of a plugin in weekly to a version requiring 2.528.3 until the dependency version was overridden in the 2.528.x BOM line, which keeps the BOM updates “safe” for consuming plugins, at the possible expense of some confusion.

[timja]

I agree with Jesse, plugins aren't randomly updating to the newer versions but its best that bom tests against the actual version that we recommend people use not some minimum version which is months old and not recommended for users as they should be on the latest bom verison.

[jtnord]

I agree with Jesse, plugins aren't randomly updating to the newer versions

Not my experience.

https://github.com/jenkinsci/commons-lang3-api-plugin/blob/main/pom.xml#L18-L19
jenkinsci/jackson2-api-plugin#307 for example

Want to test a workflow job? in your plugin? go get yourself a .3 Why does workflow-job need a .3 of this line? answers on a post card to "it does not, its due to a bad transitive dependency or a mistake, BBC Broadcasting house, London. SE1 1AA".

I can quite easily find more examples but this is not a great use of my time. Once an API plugin goes "oh I will use a .2 or a dot .3" it becomes a right PITA. Failing the BOM as a bom requires a lower bound of the LTS than the plugin would then be an :alarm: for the plugin author as they 99.999% of the time do not need to pick up that .2/.3 release.

[timja]

Those 2 pull requests match the expected and recommended behaviour though.

That pull request was raised in July at that point 2.504.x was the current line and your references are for 2.479. Previous ones should use .3.

Use .1 of most recent active line, and .3 (or later) of previous lines: jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline#choosing-a-version

I have a lot of plugins that have automated dependency updates and bom going through all the time and I cannot remember an unneeded dep update, sure the .3 updates are annoying when they kick in but its a one-time thing to update.

[jglick]

Right, I am not aware of any actual problem here. Again, we could use the sample-plugin jenkins.version to enforce that plugin maintainers do not gratuitously pick a .2 or .3 of the current LTS line (before .1 of a new line is published), if this has been a problem for anyone. I do not have a strong opinion either way.

[MarkEWaite]

Right, I am not aware of any actual problem here.

I've needed to update from ".1" to ".3" in the pom file of a plugin that is based on an older line. However, that may be because my actively maintained plugins update their dependencies weekly and my less actively maintained plugins update their dependencies monthly. I process dependency updates soon after they arrive because I want to know if a dependency update will harm the plugin and because I prefer having no pull requests open in a repository when possible.

I don't mind making that type of change (for example, from 2.479.1 to 2.479.3) but I've definitely had to make those types of changes.

[jglick]

I've needed to update from ".1" to ".3" in the pom file of a plugin that is based on an older line.

Again, that is normal and follows our recommendations. The discussion here is about the micro release of the currently active LTS line; any plugins needing to set a baseline to this line are expected to stay with the .1 until the subsequent LTS line starts.

[MarkEWaite]

that is normal and follows our recommendations

I agree that it follows our recommendations. My question was asking if our recommendations should change based on the concerns expressed by @jtnord and @rsandell. I think that their recommendation is trying to avoid updates from ".1" to ".3" in plugins based on older Jenkins versions.

In the example from James, Jackson 2 API plugin currently requires 2.479.1. If it updates to the final version of the plugin BOM for Jenkins 2.479.x, the Jackson 2 API plugin will need to require Jenkins 2.479.3 instead of Jenkins 2.479.1 because one or more dependencies of that plugin require Jenkins 2.479.3.

The developer documentation recommends choosing the ".3" of the older line, but I'm not understanding the benefit of that instead of choosing the ".1" for the older line. The documentation says:

• If you are based on the currently active LTS line, try to stay on the first release in that line (2.xxx.1) unless you have a specific reason to depend on a subsequent micro release (such as a need to test against a recently released security fix).
• If you are based on a historical LTS line (at least one release in a newer line has been published), prefer to depend on the last release in that line (typically 2.xxx.3).

Are there negative consequences if the documentation were to recommend that developers choose the first release in the historical LTS line just as they are recommended to choose the first release in the current line?

[jglick]

jenkins-infra/jenkins.io#4876 (comment) 😁

[rsandell]

A while back I was trying to get an API plugin hosted and it got blocked until I made the Jenkins dependency a .3. It made me quite furious 😅 eventually I rebelled; made it a .3 to get it hosted in the org and the first commit after that was changing the dependency back to .1 🤓